Day two of the speaker workshops and of course they're here at ultimately here at DEVCON and
let me tell you I think first and foremost on a very personal note we were just talking about it
this is a lot of people here you know joining us so early on a Saturday morning because I'm pretty
sure a lot of you folks here I think a lot of people may have had a few late and I hadn't had
a late night did anyone go to concert last night anyone go to concert I heard it was really good
also blast from the past you know from that 2000s as well who here this is your first DEVCON
it's just yeah wow it never cease to amaze me it never cease to amaze me the number of people who
who attend DEVCON for the first time here and looking at the room is usually like at least a
good 50 60 60 70 percent is like first time here on a personal note my first DEVCON was in 2000
and 2006 or DEVCON 14.
and you know right then I had knew nothing and I absolutely knew absolutely nothing and you know
what I learned from that first DEVCON was it really really makes a big difference when you
work with other people collaborate to learn this much just try to eat up and learn from the
experience I know it's very hard to do now I know it's very hard to do now because I've heard I saw
on the social media page that there was a lot of people who were really interested in the DEVCON
pictures that is an absolute like uh I don't even know what the right word is uh zoo uh getting into
the getting into the tracks and I know it's hard harder to do here at the main DEVCON but uh you
know you definitely have spent your day wisely already uh here at the packet hacking village
because it's a little more intimate and plus by although it's a little far out it's definitely
a lot intimate if you uh don't believe this this is what a DEVCON track was like 10 years ago
it was nice and small and intimate now it's like a stadium I mean that's the biggest difference
and uh he this is the reason why I still come to DEVCON it's the packet
hacking village and I'm not sure some of you heard that I said
um the reason why I still come to DEVCON is because my first experience you know at DEVCON
was working it was was uh what they call the table of doom the wall of sheep and working
with the people at the wall of sheep when I had my first DEVCON gave me the networking and security foundation
I never got out of school.
I never got any of that out of four years of college.
And a lot of people still don't even get that stuff out of four years of college,
and that's why I'm still here working for the Packet Hacking Village.
The only big difference now between the Packet Hacking Village then in 2006 versus as it is now,
I mean, it was just a username and password posted on paper plates in 2006.
Now what we have here, we have the speaker workshops.
We have the wall of sheep.
We also have a bunch of learning opportunities as well.
If you are new to network and packet analysis, there is Packet Detective all the way in Neapolitan 1.
It's like to my left.
There is, if you're really, really hungry for this stuff
and you think you're really good at dissecting networks and PCAPs,
there is Capture the Packet,
which is traditionally a Black Badge event.
We also have the Wi-Fi Sheep Hunt.
We have Honey Pots.
And we also have Sheep City, which has returned.
And Sheep City, what it is, is just a bunch of...
You might have seen a little train track that is out there.
You may see a little train track.
And there's a big bottle of booze that has an IoT thing to it.
There's a whole bunch of routers that were donated by 360.cn that were from China.
And if, as far as I know, if you can break into them, I think you can take one home.
We don't know how any of that stuff works.
We had trouble trying to get the manual because no one can read Mandarin here.
I think some people, we finally figured it out.
I don't know. It's all on display there.
But, you know, knock yourself out.
Just knock yourself out over there.
With that said, actually, with that said, just mentioning about 360.cn,
I want to take a brief opportunity to also say, you know,
if you take a look around the village, if you take a look around even here,
like, you know, the decor for this room and for this village,
none of this stuff comes cheap at all.
And we are very grateful for the number of sponsors that we have
that have made, you know, this year's Packet Hacking Village possible,
you know, with all the free swag and all that for the attendees.
So the Wall of Sheep title sponsor is Splunk.
Packet Detective sponsor, Fidelis.
Capture the Packet title sponsor, Packet Slid.
Capture the Packet Platinum sponsor, Talos.
Sheep City title sponsor, Dark Matter.
Sheep City sponsor, 360.cn.
And the Honeypot title sponsor, 802 Secure.
And so those are our sponsors.
We thank them.
But more importantly, most importantly, we want to thank you for spending the morning here.
In a few minutes at 1010, what we're going to do is we're going to introduce two,
to kick off this morning's speaker workshop,
we could, two old friends and two DEFCON veterans,
Vivek, Tomas, and they'll talk about making your own 802.11ac monitoring gadget.
And you won't be disappointed, believe me, because they've come quite a bit.
This isn't your first time.
And we always welcome you.
We always welcome you back.
In a few minutes, I'll just give you the intro.
But does anyone have any, oh, one keynote, one note here.
If you have any questions, thoughts for any of the talks, the mic is right there.
You know, at the, you know, when it's time for question and answer, please feel free to use the mic here.
Oh, also, very important.
We ask, we get, we have a lot of people who ask questions.
They ask us each and every, almost like each and every talk, each and every talk, you know,
what will the talk, will these talks be made publicly available?
The answer is yes.
And this is how it works.
We have a video, we have a video and AV recorder guy over there.
Thank you so much, by the way, for all the, everything that you've done for us, for so far at DEFCON.
So, all the talks for the speaker, speaker, speaker workshops,
I have a video recorded.
The videos for all of our talks, for each and every one of our talks,
will be made available at the same time as the DEFCON video.
That usually takes two to three months.
However, even better than that, what about the notes and PDF slides?
Slides for all, almost all, if not all, of our speaker workshops,
unless it's like into serious intellectual property and corporate matters,
they will be made available within the next two weeks on the Wall of Sheep website, wallofsheep.com.
So, talks, all of our talks, this talk, will be not only video recorded,
but your slides will be, slides will also be made publicly on the Wall of Sheep website.
Okay?
So, yeah, all the content is there for free for the taking for future use and future reference.
One last keynote, one last note before I make the introduction to Vivek and to Tomas.
I want to give, start the morning off also to give each and every one of our public service announcements.
This is something that I've made over every so often, is a public service announcement,
which is a serious problem that is affecting cyber security and tech community,
and that is sexual harassment.
I mean, just, this is absolutely not tolerated here at Packet Hacking Village and with us.
It's a no-no.
I mean, don't do anything dumb.
Don't do anything stupid.
Don't give cyber, don't give this community and tech more black eyes.
Because this is a, this is a matter that has affected us,
because we had a few volunteers who were victims at the end of last year's DEF CON.
This matter is really, really affecting the community.
I just want to make everyone aware of it.
You know, it's absolutely not tolerated.
Absolutely not tolerated.
Definitely also take a look at the Code of Conduct.
Don't do it.
Don't go there.
Don't do anything dumb.
So, now, with that said, I've rambled enough for ten, for almost ten minutes, you know.
So we might as well just kick it off, day two of the speaker workshops at the Packet Hacking Village.
And I said earlier, you know, we're going to start this speaker workshop with a bang,
because we have two old friends and two DEF CON veterans with us today.
I think, how many of you here use, either go to, how many people go to security tubes?
Anyone go to security?
Okay, you have an audience.
Aircrack NG?
Aircrack NG?
Okay.
And these two need no introduction.
We've got security tube and Aircrack NG.
Vivek, Tomas, it's all yours.
Ladies and gentlemen.
Thank you so much for the introduction.
It's always a pleasure and an honor to be invited to the Packet Hacking Village.
And thank you all for coming early in the morning.
You know, we were always worried, 10, 10, you know, nobody shows up.
But thank you so much.
So we are going to be talking about making your own 802.11ac monitoring hacker gadget.
My name is Vivek.
And I have Tomas along with me.
I'm just going to run through our introductions real quick.
I've been hacking for the last 15, 16 years.
Started my career as a low-level engineer.
Spoke first in DC 15.
So it's been 10 years for me.
Broke web cloaking.
Discovered a couple of attacks, the cafe latte.
Won a couple of competitions.
Tomas and I speak and train at multiple conferences.
We've been running the Wi-Fi training at Black Hat for the past five years.
I also run SecurityTube and Pentester Academy.
So you probably already know me.
Well, those of you who have used AircrackNG or any of the GUI tools like FernWifi, Jerix,
and all those ones that are using underneath AircrackNG.
I also created a long time ago the offensive security course, Waifu, which has been renamed to Virus Attacks.
And I speak and train at multiple conventions.
I'm now self-employed, so I do InfoSec trainings, Linux consulting, and software development.
This was supposed to be back.
I authored a couple of books.
I think while playing with the keyboard it probably...
Okay.
The agenda.
So we have a lot of exciting things today.
We are going to be looking at 802.11 basics.
Understand the current challenges at trying to monitor 11ac.
Look at different commodity hardware we could use to get started.
And then see how we can create our own custom OpenWrt solution.
So we could pretty much run tools like Aerodump, Aircrack, Host, even Python on some of these commodity hardware routers.
And create your monitoring attack defense platform.
After we cover that, Thomas will show you how to go ahead, capture the packets, analyze them using a little tool he's created called WifiBeat.
Okay.
So let's step back if you remember the last 10 golden years of Wifi monitoring.
Right, when we had just A, B, and G networks.
Typically a single input, single output system.
Extremely easy, right?
We had our alpha cards, the directional antennas.
Set the card on the same channel as the access point.
Start monitoring.
You get to see all the packets.
Right? It was wonderful. It was paradise.
And then N and 11ac came along and started making matters bad for us.
So what is so complicated about N and 11ac?
What is it about N and 11ac that requires us to create a custom solution?
And why using a USB based adapter, which we are all used to, does not scale or work properly as we move along 11ac speeds.
So the very first feature with N and 11ac have is channel bonding.
Now putting it simply, with A, B, and G what we really had was 20 megahertz channels. Right?
N and 11ac said, hey, why not combine both of these channels to adjacent ones.
There are other variations as well.
And create a 40 megahertz channel.
From our perspective, if you want to monitor a network using 40 megahertz, using channel bonding.
You need to ensure that your card supports channel bonding as well.
A very common question which I get from pen testers in the field is, hey, you know, I am monitoring this network.
I see nothing.
Well that is because either you have a 20 megahertz only card or you have a card which can operate on 40 but you set it on 20.
One of the most common mistakes I have seen people do.
So channel bonding requires you to have compatible hardware and to make sure that you set the channel appropriately.
Then we have 5 gigahertz channels. Right?
A bunch of channels.
Some of them of course you can use 36 to 48.
And then you have DFS channels.
Which are dynamic frequency selection channels.
So on these channels there could be radar or other communication happening.
And what access points are required to do is sense those channels.
And if they see that there is any form of radar or any other communication then to back off and not use them.
Now this is great.
Unfortunately the bad guys if you are monitoring a network don't play by the rules.
So I have even seen a lot of million dollar 11ac monitoring products actually back off from channels where there is radar communication happening.
But attackers can very easily create back door APs, rogue APs on these channels even though there is probably something happening there. Right?
So our monitoring solution also requires that we sense and monitor all channels regardless of other transmissions.
Which might, depending on the jurisdiction you are in, mean you need permission.
So from an attacker or a defender's perspective we need to make sure that the regulatory domains which we are setting on the monitoring platform is coherent with what we want to do.
Right?
Again, one of the most common mistakes I have seen people do.
They start monitoring, don't see any traffic from some channels, they just assume nothing is happening there.
In all probability your card is probably not even going on those channels.
Okay, if that wasn't enough, NNAC has MIMO. Right? Multiple input, multiple output.
Very simply put, this is really multiple transmission and receiving antennas, all of them sending out the signal.
The DSP on the receiver side is going to pick up these signals from these different receiving antennas and combine them intelligently so you have a much more powerful, stable signal.
Now with NNAC, they actually brought in an additional complexity.
So the ideal case is if you want high reliability, you would want to transmit the same signal.
Let's say from both the antennas. Right?
Now in NNAC, you have what are called spatial streams.
So this is really trying to go ahead and get higher throughput at the cost of reliability.
So what they do is we have a high bit rate signal and they split that signal up and every antenna is actually going to transmit part of that signal.
So now each antenna is really sending a part of that data stream.
On the receiver side, they have a lot of DSP going on which can intelligently combine that together.
So essentially, now we have multiple spatial streams which send data independently of each other.
In the case of N, we can have four streams. That is the maximum.
I've seen most commercial equipment go up to three streams.
But you can do four streams.
With AC, we can go all the way up to eight streams, which is quite a lot.
Just to give you an example, all your phones, or rather most of your phones, which even are 11ac compatible, are probably single stream.
Most of your laptops probably are two stream.
The last I checked, only the MacBook Pro was three stream. Right?
So keep that in mind.
From our perspective, if you're monitoring a network which is four stream or eight stream and you do not have compatible hardware,
you're probably not going to see most of the data being sent. Right?
Again, very, very important.
So pen testers buy equipment. Again, I've seen that teaching Wi-Fi security now for ten years.
They go to the field, start monitoring, don't see anything.
And then you realize they have a single stream adapter.
While the network is operating completely in four streams.
So this is important. Keep this in mind.
You have to purchase equipment which is compatible with the number of streams of the network you're trying to monitor.
Okay, if that wasn't enough.
They also came out with CU and MU-MIMO.
So what is this all about?
CU-MIMO is really 11n and AC wave one.
Now we talked about the fact that we have multiple streams. Right?
Four streams, eight streams. That's what these APs can do.
But the clients themselves unfortunately can be one, two stream in general.
So with CU-MIMO or single user MIMO, the access point time division multiplexes between these devices.
So let's say we have a laptop which is four stream and two mobile phones which are single stream.
The access point is going to multiplex between them.
So it talks four stream to the four stream laptop.
It talks, you know, single stream to the single stream mobile phones.
As you can clearly see, that is not optimal. Right?
It's more like a hub model where when an AP is talking to a device, it's essentially just occupying the channel with just that device.
So with MU-MIMO, which is really bleeding edge, 11 AC wave two.
What they try to do is actually simultaneously talk to multiple devices.
So in that figure which we have, let's say the laptop has two streams and we have two mobile phones, single stream each.
The access point can simultaneously talk to the two stream laptop and the two single stream mobile phones. Right?
There are some limitations. There are some cases of how grouping and all of that happens.
But this is the overall view.
Another example, a four stream AP on the left can talk to four single stream clients.
Or the same four stream AP can talk to two single stream clients and one two stream client. Okay?
Okay. More challenges.
And as you can clearly see how vastly ABG versus NNAC differs.
Especially as we move towards wave two.
So additionally, what we have with AC is also beam forming.
So what is beam forming?
Now, previously in the good old days, we used to have an access point, typically omnidirectional, sending out power in all directions. Right?
So which means if the AP is communicating with a client here, an attacker is located in the other direction, he might still be able to pick it up.
Unfortunately, what they decided to do, and this is unfortunate for us, good for, of course, the larger consumer market,
is now they actually try to detect the direction in which the client or the device, either party is communicating with,
and they try to channelize the energy in that direction.
So this way, it is more directed, which means you get more range, and of course, this is an optimal solution.
From our perspective, location matters.
Right? You just can't get away now with just having, I mean, the physics is against you.
Unless you are Neo from Matrix, you are probably going to have to have more sensors or an optimal location.
Okay. So to summarize, NNAC actually bring about a lot of additional features, which is going to make monitoring more and more difficult.
Couple of them, as I mentioned.
Location, channel width, you know, we have 2040. With AC, that can be 80 and even 160.
The 160 MHz equipment, I have not seen too many enterprises use, but the adoption is increasing.
Probably a year, year and a half from now, you should see more and more 160 MHz 11AC networks.
We are packing more bits per MHz, so the QAM, or the Quadrature Amplitude Modulation, that is increasing as well.
All the way to 256 MHz.
QAM for 11AC. Spatial streams increase, beamforming, MIMO, and all the stuff we talked about.
Of course, with all of this new technology coming in, you have the monster APs invading, right?
You may have seen a lot of these photographs with 6, 10, 12, you know, how many ever antennas.
And with, of course, every antenna getting added, the price gets bumped as well.
Some of these are pretty powerful platforms. And many of them are actually based off OpenWRT and other Linux platforms.
The sad part, not all vendors acknowledge that publicly, but if you just try to log into the box and do a little bit of digging,
you'll actually find almost 50% of these APs are just running Linux based on OpenWRT, DDWRT, or one of the other variants.
Interestingly, when I bought the ASUS one for one of the trainings we were conducting,
I even saw this little home assessment kind of banner ad. I don't know if you've seen it.
So, now you can actually invite a wireless expert to your home.
So he can lay everything out for you in an optimal way.
And of course, then your neighbor in the next apartment decides to change his AP's locations.
And then you have to call him all back again.
Okay, this is just a diagram of how you could go ahead and use multiple radios and chain together more and more bandwidth.
So, to summarize, these are the challenges we are looking at.
Beamforming, challenge of course, location matters. Spatial stream count.
We have to ensure that our capturing and monitoring platform has equal number of spatial streams as the network we are lying to monitor.
High speed. Now, this is really where I'm going to disappoint many of you.
Because as these networks are really fast, unfortunately you'll find that USB based solutions aren't going to work anymore.
So I'm sorry if I had to break the bad news. But we really cannot use USB anymore.
Unless all you're interested in is just macro statistics. Right?
If you want to do deep packet inspection, look at what is happening.
You know, at a much more micro level. Detect threats and all of that.
Anomaly time correlation or spatial correlation. You do require a much more robust solution.
Which is what we're going to talk about.
Multiple channels. Channel bonding. Again, compatible hardware.
Okay. So, as I mentioned, I'm going to go a bit fast. We have a lot to cover.
I'll take call questions at the end and even outside.
Okay. So, as I mentioned.
The Wi-Fi adapters, especially the USB ones, aren't going to be very useful.
So, what we want to do is AP based monitoring.
Now, there are many commercial APs available which are based on open source.
I've tested probably over a hundred. I'm not kidding you. Over a hundred.
The ones which I've found really good, reasonably priced,
is the Ubiquity range. I don't work for them.
And I don't have a referral code anywhere there. So, just so you know.
So, Ubiquity actually has a series of UniFi APs. Some of you might have already bought it.
These are based out of OpenWrt. I don't see that acknowledged anywhere on their website.
Or maybe my search skills are bad. But after digging a little deep, what I've found is it's just OpenWrt.
So, what we are going to do is pick up one of these access points and see if we can do something with them.
First with whatever manufacturer firmware is in it and then see how we can load our own customized firmware
so we can port attack tools and all of that in it. Okay?
So, the USC AC Pro. Now, these little access points are supposed to be either cloud based
or to be controlled by a local embedded controller.
Now, when you buy them, my recommendation if you want to use it for monitoring,
do not connect and provision them.
Rolling back all of the stuff the provisioning scripts do is a couple of hours of work.
So, just buy them, take it out of the box, power it up and just wait for two to three minutes.
What happens is,
the AC Pro tries to get a DHCP address so it can connect to a cloud system.
When it fails, the entire Unify series goes ahead and assumes a static IP address which is 192.168.1.20.
Right? It's a predictable single IP which the entire range of APs take.
The good news, SSH is enabled.
Because SSH is what is used to provision these APs.
Do we have to reverse engineer the firmware?
You know, use an IDA, do something to get the default username and password? No.
Someone posted that on the forums. The default username is UBNT.
And the password is? UBNT.
So, what I've done is,
this is an access point which I've bought.
Contains the manufacturer firmware. No modification made.
I've just powered it up. It uses PoE.
And now, I'm going to go ahead and log into the AP.
So, it is going to be difficult to type with one hand.
I'll try.
Okay. So, the IP address as I mentioned was 192.168.1.20.
And the passphrase or the password is UBNT.
As soon as you log in, people who've worked with embedded systems or routers,
that must be a familiar prompt, right?
Busy box. Is this visible at the back?
Okay. Now, the first thing which I like to do,
and I'm kind of running you through how I experiment with newer platforms which I look at,
is just hit that twice and look at all the built-in utilities,
all the utilities available.
A lot of times, manufacturers may have, you know, most utilities you would require,
which is the case for the Ubiquity series.
So, if I were to just scroll up,
I always love to see iwconfig
because this allows me to quickly look at interfaces, you know,
without having to go around in circles.
And then, I actually find that there is a wlan-config, which is fantastic.
Come to that.
We have wpa-supplicant, host-apd,
and a couple of other utilities.
So, let's actually run iwconfig and look at what interfaces are available on this system.
So, we have at 0 and at 1.
And if you notice, at 0 is currently in master mode.
So, when it says mode master, it just means it's an access point.
Okay?
We can see this is the 2.4 gigahertz radio.
So, this actually has two radios in it.
One for 2.4, the other for 5. Fantastic.
So, we don't require two APs.
We can just use one platform to monitor both the bands.
Then, you have at 1.
Interestingly, this seems to be managed mode.
And at 1, of course, is the 5 gigahertz radio. Great.
Unfortunately, can't do anything with these interfaces.
So, what I'd like to do is destroy these interfaces
and go ahead and create monitor mode interfaces in turn, which we can use.
Right?
Again, a lot of hit and trial, and what I've actually found is
even though you should be able to destroy these interfaces directly,
it's always a good idea to kind of bring them down before you destroy them.
Okay?
So, let me bring these down.
I'm going to bring these down.
At 0, down.
And then at 1, down.
Now, to destroy them, we are going to use the WLAN config utility.
Again, let me reiterate.
Every single utility right now is built in with the manufacturer firmware.
Right?
These are not my additions.
We'll come to my additions later.
So, the usage to destroy an interface is as simple as it can get.
WLAN config at 0, destroy.
And then WLAN config at 1, destroy.
Now, if we look at the list of interfaces,
we see that at 0 and at 1 have been destroyed.
Right?
Now, keep in mind, this is the running config.
I haven't saved this in a persistent way,
and I'll talk about that later when we look at our customizations.
Right?
So, now that we've destroyed both of these,
we'd like to create monitor mode interfaces which we can use.
Again, WLAN config comes to our rescue.
I mean, unbelievably simple.
All you have to do is WLAN config.
Let's name the monitor mode interface.
So, let's actually call this mon0,
the first monitor mode interface.
I'm going to say create.
And again, all I'm doing is copying this command out.
WLAN dev.
Now, you want to create this virtual monitor mode interface
on top of one of the cards.
So, I'm going to be using WIFI 0.
Right?
The first card.
And then, the WLAN mode.
I am typing with one hand, so.
And of course, the option is monitor.
Okay.
So, what this is going to do is create a new interface mon0
as a virtual adapter on top of WIFI 0.
And this will be a monitor mode interface.
Right?
So, I hit an enter.
It goes ahead and echoes back mon0,
which means everything went well.
Similarly, I'm going to go ahead and create mon1
on top of WIFI 1.
Fantastic.
Now, we have two monitor mode interfaces.
Let's bring them up.
So, if config mon0 up.
And then, mon1 up.
Let's type in iwconfig.
And there we are.
Right?
So, what we've done so far, if I were to summarize,
is we've removed the interfaces the manufacturer had by default.
And we've created monitor mode interfaces on the box.
So, now, let's actually set this to a channel.
So, I'm going to go ahead and say iwconfig mon0.
Channel 6.
Now, we'd like to look at the packets.
Good news, tcpdump is also in there.
So, tcpdump-i mon0.
And there you go.
So, we are now monitoring 2.4 gigahertz, channel 6.
Where's the clapping?
Thank you. Thank you.
I haven't slept the whole night because I had to kind of flash firmware.
So, you guys have to keep me awake.
We have a booth and just trying to flash firmware for it.
Okay. So, this is good. This is great.
Bad news, right?
The device does not have storage capacity.
It probably has around 10 megabit or something like that.
Well, what they did is they've kind of removed some functionality here or there.
But I'll show you how to find the disk size in just a bit.
But we can't do anything on this device.
Well, we can look at the packets using tcpdump and that's great from a research standpoint.
But, you know, what more?
So, what we can do is stream packets from this device using SSH back to a central server
where we can analyze them as a pcap file or actually even just have Wireshark receive that stream and look at it live.
So, let's do that.
This is the command.
Let's explain the command in a bit.
Okay. So, what this command does and now I'm running this on my host machine, right?
Which is connected to this box.
Now, keep in mind that you could connect this to even your local network in your enterprise
and still stream it to any server.
This doesn't necessarily have to be connected physically to the collection, you know, station, right?
So, all I'm doing is logging in using SSH.
The user name is ubnt.
The IP address is 1.20.
Twenty more minutes? Okay.
I'm just going to be a bit fast.
You don't have too much time.
And then I'm going to invoke tcpdump, give it mon0, tell it to snap the entire packet length
and then write it to, you know, stdout which comes back over SSH and gets piped into Wireshark.
K is start immediately.
I is interface which is the input, right?
So, once I go ahead and run this, Wireshark pops up assuming you have that stored locally.
Now, the moment I log in, packets will get automatically streamed into Wireshark.
Isn't that cool?
And you can go ahead and write your own channel hopper, you know, simple bash script or, you know, something similar and that work as well.
So, this is how you can go ahead, get the packets from the device to a remote device.
This is a remote collection server.
You could even just go ahead, redirect this into a file and then have multiple utilities read from it.
Great.
Now, this isn't enough, right?
We want to run Thomas's tool.
I mean, he's been a good friend for ten years.
This is the least I could do.
So, we want to run arrow dump ng on it.
We want to run, you know, python on it.
We want to run pretty much whatever we want.
Right?
So that we can convert this into a fully customized platform.
So, there are a lot of steps.
What I'm going to be doing is I've shot videos of every step which you guys can look at later of how to install the firmware.
It's pretty straightforward.
We don't have enough time.
So, I'm just going to go through it in the slides and at the end, I'm going to give you a link which you can use.
So, all we do is download a compatible open WRT.
And basically write that onto the device.
Okay?
Using MTD.
Once we do that, we can restart the device.
Extremely straightforward.
Nothing complex.
Restart the device.
You get a familiar open WRT prompt.
If you haven't used it, open WRT is, you know, an embedded Linux used by a lot of commercial routers, both home as well as enterprise grade.
Extremely flexible.
Has a lot of package management and support.
From a security perspective, Aircrack NG, MDK3, Skp, a lot of these tools are supported in the package manager itself.
So, you don't have to do any of the cross-compiling exercise.
The next thing, of course, which we notice is we only have around 10 megabit.
So, we are going to use a technique called extroot which allows us to extend the root onto an external storage device which is a USB key.
So, this is the modified one.
And if you notice, I have a USB key connected to it.
Right?
It's a 16 gig one, though you can pretty much go as high as you'd like.
So, you could have that external storage and dump everything in it or load the OS and other things from it.
A lot of possibilities.
Okay.
We have to install the ATT 10K drivers.
Again, everything is there.
No cross-compiling required.
Now, what I'm going to do is...
I have gone ahead and put all of this on that device.
And I'm going to now connect to that device and show you how it looks like.
Right?
The entire customization process is very simple.
Just you have to follow the steps.
I'm going to give you videos for that.
Just a second.
Okay.
So, I am connecting to the custom AP now.
Okay.
The demo gods are with me so far.
Let's see if a simple SSH works or if that is what is.
Okay.
Hopefully, this will work.
So, the OpenWrt system, I am root on that unlike UBNT.
I had to check what privileges UBNT was but I'm probably sure it's close to root.
I didn't try installing anything.
And the IP address of my customized device now running OpenWrt is 50.150.
I'm going to SSH into it.
And there you go.
You have to change the welcome message.
Right?
Whymon.
That's all the customization I did.
So, with the manufacturer firmware, of course, we had to go through all the pains of creating the monitor mode interface and all of that.
With the customized one.
Okay.
Looks like the USB key.
It's not connected.
Hard to happen.
Okay.
Okay.
Okay.
So, this does take roughly I think a minute or two to start.
Okay.
Just give me a second.
Give me a second.
Okay, I'm waiting for an IP address.
I should have shortly.
Okay.
Okay.
There we go.
Okay.
So now that I have the USB key connected with all my customizations,
as soon as we log in, you see we see WLAN 0 and WLAN 1.
Do you see that?
So what I've done is I've changed the init scripts,
and these automatically are set to monitor mode.
So we don't have to do anything.
It's just plug and play.
I'm going to quickly just demo three tools.
The videos have a lot more, and then I'm going to give it to Thomas.
The first tool we all love, and we have the creator here with us,
is, of course, AeroDumpNG.
And there you go.
Claps.
I'm going to remind you of it.
So here is AeroDumpNG,
and Thomas has a little plug there which says contact the author.
This is his trick so that he gets fan mail.
So,
along with that,
what I'm going to do is run another tool called Horse.
Now this is actually, you know, quite an underappreciated tool in my opinion.
Horse allows you to do scanning on 5 gigahertz
and is aware of channel bonding and all of that.
There you go.
I use this actually to, you know, hop channels, do other interesting things.
They have an API.
I would highly recommend looking at this tool.
Now, right now, if you notice at the bottom right, we are on channel 60.
At the rate 80 means 80 megahertz, right?
Right here at the bottom.
Might not be too visible.
C8-036 at 80.
So channel 36, 80 megahertz.
I can go ahead and tell it to scan by selecting S.
And this now starts scanning all the channels.
And you can even set it for HD 20, 40, 80, 160, whatever combinations you want.
It has a config file which you can change and modify as well.
The videos have more detailed information.
The last thing I want to quickly show is...
And by the way, you can run MDK3.
You can run all your attack tools on this, right?
Air replay, injection attacks, everything.
The last thing I want to show is for people who love Python.
Skp, right?
So extremely simple code.
It's just a POC just to show you that we can run Skp very easily.
So this is like the simplest Skp code ever.
All it does is monitors the interface.
Takes a number of packets and just prints the summary.
Okay.
Now on the other side, there you go.
So there it is.
Skp running.
People remember.
And of course, you can pretty much port more sniffers and injectors if you want.
So I'm going to give it to Thomas now.
What he's going to show is how you can now take all of these packets and do deep analysis.
You have 10?
Great.
So I created.
Great.
So I created recently another tool called Wi-Fi Beat.
So you store all your packets parsed in Elasticsearch and you can search for them using Kibana or you can use other tools such as ElastAlert to create alerts and send you emails or using other channels.
So I'm going to quickly go through, explain the different Elastic tools, what is Beat, Wi-Fi Beat itself, and the two libraries that I created along with it.
And a quick demo and let you know where you can.
So all the Elastic tools.
So you have Elasticsearch, which is pretty much a NoSQL database and stores JSON documents.
And you have Kibana that does visualization, so it connects to Elasticsearch to do that.
You have Logstash that can connect also to Elasticsearch and stores all the logs from a bunch of different sources.
And you also have Beats.
And Beats are pretty much data shippers.
And it can send data either to Logstash or to Elasticsearch.
Or directly to Elasticsearch.
So here are some of them.
You have FileBeat that reads log files.
Much lighter than Logstash if you only need to read log files.
You have a MetricBeat that does metrics.
WinLogBeat that does Windows logs because Windows had to do something different.
HeatBeat that shows the uptime.
And PacketBeat that does packet monitoring and parsing.
You might think that PacketBeat is the one you're looking for.
But no, it doesn't understand.
PacketBeat is the radio tab, which is the header that comes with Wi-Fi packets, the metadata.
So basically you have all the information.
It says which channel is best captured on, the signal, and a bunch of other information.
So that's the error that appears when you start a program.
So I created Wi-FiBeat as well as two libraries that I needed for it.
So Wi-FiBeat captures all the packets from one or multiple wireless interfaces.
And stores them on Elasticsearch.
So you can even read PCAP files.
You have full packet decoding pretty much like Wireshark filters.
So you can transpose pretty much your Wireshark display filter in Kibana.
So you can search for the packets.
You can also do decryption if you'd like.
But in that case you have to provide the key in the configuration file.
It doesn't do any cracking whatsoever.
You have to use Aircracker and any other tool to do that.
Another library that I created was simplejson-cpp.
A C++ library.
Let's just do a simple generation for JSON.
Here's what it looks like.
So you have some of the codes.
You create an object here.
That's the main document.
You create values.
And you simply add all those values to the main document.
Here I create another object.
And I create a key and value in that object.
And I finally add that to the main one.
For example, here is a vector, an array that we add to the main object.
And then I export it to a string.
So that's very easy, very simple to create a JSON.
I used to use rapid JSON, but that one was very complicated.
It's very nice, very fast.
But the problem, it has some very weird memory allocations.
And you had, for example,
for this one you had to do like four lines of code.
And considering the amount of code that is even in Warstrike decoding,
27,000 lines, that was out of question.
Not maintainable.
The other library that I did was ElasticBeat.
And that is, both of those libraries are header only.
So you don't have to compile any code.
So you just include it in your main project.
And then it gets compiled with it.
So for now, it uses rapid JSON for parsing JSON documents.
And it inserts stuff using the bulk API from Elasticsearch.
So this is what it looks like.
So you connect to Elasticsearch here.
So on our local host, we display the version.
Here's another example where you can get indices.
All tables, pretty much.
You can check if an index exists.
And then create it.
And here's, for example, that bulk request that we do.
So you send a bunch of documents to Elasticsearch to store them.
So you don't do one by one.
All of them are going to be sent in one query.
You can do either index or delete.
So the index is pretty much insert for those who have done
a relation of databases.
And finally, you can see if there are any errors.
If there are any, so it will just display that into the error field.
And if not, you get all your IDs back in case you want to process them.
So to summarize, so the Wi-Fi bit is GPLv3.
It parses and stores data in Elasticsearch.
And you also have Kibana dashboards with it.
And it's in C++.
The two libraries that are created are in BSD license.
So you do whatever you want with it.
You can even include them in your commercial product.
It doesn't matter.
And they're both C++.
So Elasticsearch bit communicates with Elasticsearch.
And simple JSON generates JSON.
So now let's switch quickly to the demo.
Okay, so now you can see I have a search field.
So in Kibana, you have three main...
Items.
So you have Discover where you see all your logs or documents.
You have Visualize where you can create visualization.
And you have Dashboard.
So here's just a search for a specific time frame because I already have a ton of data for that.
And here's one of the documents.
So you can see here exactly all the data parsed in the database.
So one thing about it is...
Elasticsearch for Kibana displays everything flat.
So you can see it here.
So that WN underscore MGT dot A S E L.
And you see a bunch of them.
A S E L dot capable CSI if reserved IREX.
And so all those things were in a single JSON document.
And here you have a different item.
So you can see that image here.
So Elasticsearch in Kibana cannot handle arrays.
So it just displays it like this.
There's a workaround.
There's a library for that for either Elasticsearch or Kibana.
And I give the link to it in the project.
So here's if you want to take a look at the JSON.
That's what the document looks like.
So the familiar fields.
In the packet.
So version, type, subtype.
So the type of the frame and subtype of the frame.
And if I look at Wireshark here.
See if I can open that one.
And I can actually take my filter all the way above here.
I just have to modify it a little bit.
Since...
Change the column to equals.
And so we have the exact same pack as well.
Different capture.
The same thing that are parsed.
So the frame control field that we had.
And you can see all the information in Elasticsearch here.
So in the dashboard.
For now I created a very simple dashboard.
With a bit basic information about a network.
So that way it looks like.
You can see a different type of frames.
The amount of frames.
You can even calculate other searches that are added.
So that you can get the amount of data.
That is stored in a...
That has been transmitted in the network.
So that's what the tool looks like when you run it.
You have the version.
The configuration.
You can change the configuration file.
If you're doing some testing.
You can make it go in the foreground.
If you want to debug some stuff.
And...
All the logs go to syslog.
So everything.
All the actions are logged to syslog.
In case you want to see it.
And you're running a background.
You have a pit file.
Very useful when you're running as a service.
So...
We already went through all that.
So a few last words.
Elastic beat.
So I'm going to add the beat protocol.
In the future.
Built in a rapid json.
Or even get rid of it.
And built in a library.
For simple json.
I'm going to do more json parsing.
With it.
And for wifi beat.
I will do persistent queues.
Support for NPK.
So some windows adapters.
Supports monitor mode.
So you can use them.
NPK supports.
Channel width.
So 5, 10 megahertz.
Even HD and VHD channels.
Which is already in the code.
But not enabled yet.
Pkpng.
And a bunch of other things.
So if you want to take a look at all the projects.
They're all on github.
Github.com slash wifibeat.
The case is.
Doesn't matter.
So you can even put lower case.
That's fine.
Or you can just go to wifibeat.org.
That contains the links to it.
And just a brief description.
Pretty good back to back.
Uh.
.