Hack Chip and Pineapples. (Part 8 of /n)
Prologue:
So if you enjoy wifi hacking I am assume you have heard of @d4rkm4tter and his insane mad scientist creation #wifiCactus. (if you haven’t, head over the the @hak5 youtube channel to see it in action, before you read any of the rest of this post).
Capturing wifi packets is somewhat of an obsession for many of us. Not sure why, I assume its like bass fishing for rednecks. My first endeavor into this was with the wifi-box-of-doom I created about 4 years back.
It was a box with 2 raspberryPis and 3 Alfa cards, to capture all them packets. Now typically when you have 1 monitor interface , the sniffer has to do whats called channel hopping. Meaning that you can miss some packets when the monitor interface is on a channel too far away for frequency spillover. And you know channel hopping is for whoosies? (not sure the plural for whoosie) @hak5darren and @d4rkm4tter agree.
Now that @d4rkm4ttter has upped the game, I decided to revisit the “capture all dem packets” This was a lot easier said than done, I have a box full of odd wifi adaptors and other assorted wifi stuff. I was even thinking of resurrecting the old wifi-box-of-doom and use that.
Then I realized it was staring right in my face, luckily I am in the possession of the wifi pineapple Tetra and Nano. (I also have an old , MKIV-clone I build, I am missing the MKV to complete the family if you are looking for a Christmas present for me). The Nano has 2 radios (i.e.:wlan0 and wlan1) , now technically I only need 3 wlan interfaces to capture most (can’t capture channel 14 , but then again channel 14 is limited in use anyway) of the packets by setting the monitor interfaces to channel 1,6,11.
Now capturing packets is one thing, making the data useful is another. The Wifi Pineapple Nano is meant to be portable, so portable=wardriving (or war-walking,war-skateboarding etc etc)
Great! Right? Well, kinda….
Cause what about the “where did we capture the data?” question? Since I will be using the usb port on the Nano for my third wlan interface , there is no way of adding a GPS dongle to the Nano. But then again the Hack Chip does have an usb hub. So yep , the idea is to use the Hack Chip to feed the GPS data back to Nano to be used by the Kismet_server running on the Nano. (I am not the first one to think this up. @chilcano has done excellent writeup on using the Nano and an Android phone for wardriving.)
For the GPS adaptor I decided to use the Holux M-241 which I had bought a long time back. I’m sure there are better adopters these days, but then again hackers make do.
So here is the setup:
By using the Y-cable to power the Nano, I wanted to make sure that the Nano operated smoothly.
So here is what happens.
1.The Nano captures on 3 channels (1,6,11) and runs a kismet_server in daemon mode.
2. The Hack Chip runs the gpsd daemon , allowing the Nano to connect to it via the usb-ethernet bridge.
3. Technically the Hack Chip can also run the kismet_client to connect to the kismet_server running on the Nano.
4. All captured data is saved on the Nano’ sd card.
This was a challenging journey. Here is the why:
The Nano has to start in total “stealth mode” , meaning all radios would have to be off at boot. After a long trial and error , turns out disabling the radios in /etc/config/wireless was the right answer.
So here is how my /etc/config/wireless looks. (XXX is where whatever setting you have) the “option disabled ‘1’” turns the radio off at boot time, stoping the hostapd to not launch.
config wifi-device ‘radio0’
option type ‘mac80211’
option channel ‘11’
option hwmode ‘11g’
option path ‘platform/ar933x_wmac’
option htmode ‘HT20’
option disabled ‘1’
config wifi-iface
option device ‘radio0’
option network ‘lan’
option mode ‘monitor’
option encryption ‘none’
option macaddr ‘XXXXXXXXXX’
option ssid ‘XXXXX’
option hidden ‘1’
option disabled ‘1’
config wifi-iface
option device ‘radio0’
option network ‘lan’
option mode ‘ap’
option encryption ‘psk2+ccmp’
option key ‘XXXXXXX’
option ssid ‘XXXXXXX’
option disabled ‘1’
config wifi-device ‘radio1’
option type ‘mac80211’
option channel ‘11’
option hwmode ‘11g’
option path ‘platform/ehci-platform/usb1/1–1/1–1.1/1–1.1:1.0’
option htmode ‘HT20’
option disabled ‘1’
config wifi-iface
option device ‘radio1’
option ifname ‘wlan1’
option network ‘lan’
option mode ‘sta’
option ssid ‘XXXXXXXXX’
option encryption ‘none’
option disabled ‘1’
config wifi-device ‘radio2’
option type ‘mac80211’
option channel ‘6’
option hwmode ‘11g’
option path ‘platform/ehci-platform/usb1/1–1/1–1.3/1–1.3:1.0’
option htmode ‘HT20’
option disabled ‘1’
config wifi-iface
option device ‘radio2’
option ifname ‘wlan2’
option mode ‘sta’
option macaddr ‘7c:01:91:5e:8e:87’
option disabled ‘1’
Now the Nano is in full stealth mode.
To truly capture all the packets you might want to change the regulation domain to match your country. I my case I wanted to capture channels 12 and 13 too. Now the onboard ath9K radios wouldn’t allow me change their regulatory domain. (makes sense) but the wlan2 radio does allow me to change it. So prior to making the monitor interfaces I issue :
root@pineapple$ iw reg set JP
Next I needed to setup a 3 monitor interfaces. (I used the RALINK USB WIFI RT5370 for wlan2 I got from the Hak5 shop, but any monitor mode capable dongle should do)
There are multiple ways to achieve this, the latest kismet_server allows you to create VIF (Virtual interfaces) However I found that setting and making the interfaces ahead prior to launching kismet_server gave me a better stable performance. (still once in awhile the wlanXmon will go down but kismet_server will automatically bounce the interface.)
To create the monitor interfaces, on the Nano do :
root@pineapple$ iw wlan0 interface add wlan0mon type monitor
root@pineapple$ iw wlan1 interface add wlan1mon type monitor
root@pineapple$ iw wlan2 interface add wlan2mon type monitor
This creates 3 monitor interfaces
wlan0mon
wlan1mon
wlan2mon
So next define these as the source interface is (/etc/kismet/kismet.conf)
So here is the kismet server config file source entry:
ncsource=wlan0mon:type=mac80211,forcevap=false,hop=false,channel=1
ncsource=wlan1mon:type=mac80211,forcevap=false,hop=false,channel=6
ncsource=wlan2mon:type=mac80211,forcevap=false,hop=false,channel=11
Note that I’m using wlan2mon for Channel 11.
Cool now we have kismet_server on the Nano capturing on 3 channels.
How to GPS? (another headache to solve)
Well like I said the Hack Chip will run a gpsd daemon to serve to the Nano.
To install the gpsd daemon, just sudo apt-get install gpsd. (if you do decide to use the same M-241 adaptor , dont use the bluetooth connection, use the usb-serial connection and issue: stty 38400 < /dev/ttyUSB0, for details go here:Holux M-241.)
By default you want to change the gpsd daemon to listen to all IPs not only 127.0.0.1 , so once installed change the /lib/systemd/system/gpsd.socket file to have the following values:
[Unit]
Description=GPS (Global Positioning System) Daemon Sockets
[Socket]
ListenStream=/var/run/gpsd.sock
ListenStream=[::1]:2947
ListenStream=0.0.0.0:2497
SocketMode=0600
[Install]
WantedBy=sockets.target
the 0.0.0.0:2497 will allow remote connections to the gpsd daemon.
Once all set then reboot the Hack Chip. Once back up ssh into it again and check if the gpsd daemon is running correctly.
If you issue netstat -lnp you should see something like:
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:2497 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp6 0 0 ::1:2947 :::* LISTEN
tcp6 0 0 :::22 :::* LISTEN
So now we have the gpsd daemon running. You can check that the gps adaptor is feeding the gps data by using the cgps client program.
chip@hackchip$ cgps
So now we are ready to feed the gps data back to the Nano kismet_server.
In the kismet.conf file :
# Do we have a GPS?
gps=true
# Do we use a locally serial attached GPS, or use a gpsd server, or
# use a fixed virtual gps?
# (Pick only one)
gpstype=gpsd
# Host:port that GPSD is running on. This can be localhost OR remote!
gpshost=[IP ADRESS OF HACKCHIP’s eth0]:2497
ssh into the Nano from the Hack Chip and test this by doing:
root@Pineapple:~# telnet 172.16.42.209 2497
This will return :
{“class”:”VERSION”,”release”:”3.11",”rev”:”3.11–3",”proto_major”:3,”proto_minor”:9}
If you get this the connection is successful.
Then its just a matter of launching the kismet_server. (see below for some more comments on this)
Extra Tips:
1. I have set it up so that there are multiple kismet server configuration files.
a) kismet.cacti.conf is the main all cool functions version. 3 monitor interfaces , gps via gpsd on the Hack Chip.
b) kismet.hopper.conf is the basic but I use wlan2 to channel hop. (why? cause I wanted to be able to compare the packet capture process)
c) kismet.default.conf is the default configuration for #justincaseshithappens
2. Instead of issuing kismet_server , I use
root@pineapple$ kismet_server -f /etc/kismet/[whicheverfileIwantToUse].conf
3. I also copied the default (or the one with my settings to /etc/config/wireless to the sd card).
why? : this way I can easily switch back to Nano Tactical mode. (i.e.: PineAp logging stuff , evil portal servicing evil stuff…etc etc.)
4.Since you will be going back and forth between the Hack Chip and the Nano, take the time to setup bidirectional key based ssh logins. (ssh-keygen, ssh-copy-id etc ) Also add the Nano to the /etc/hosts file so you can do : chip@hackchip$ ssh root@nano .
5. @_Kustodian_ tells me that this setup need a cool name and suggested #wifiBonsai, now I agree its fitting but I rather think of this as the #miniWifiCactus part of the #wifiCactus family. After all the setup is very similar. If it was a non-pineapple setup I might have gone with #wifiBonsai.