[Howto] Wireless injection using Odroid Wifi Modules

Moderators: meveric, mdrjr, odroid

[Howto] Wireless injection using Odroid Wifi Modules

Unread postby mad_ady » Mon Mar 21, 2016 6:46 pm

In my previous article we learned how to configure the Odroid WiFi Modules (0, 3 and 4) in monitor mode in order to listen to wireless management traffic with Kismet. In this article we will test traffic injection and analyze open networks and various protection methods used in addition to encryption. We will finish off with some attacks that don't involve breaking the network encryption. Although this article will get technical, its purpose is to get you familiarized with how wireless networks work and is not designed to turn you into a script kiddie that doesn't understand what they're doing :) If you haven't read last issue's article about Kismet, do so now because we will be building on past experience. As always, breaking somebody's network without their consent is punishable by law, so try this only against your own networks.

Prepare for your injection

The term "injection" is used to denote the generation of wireless management traffic based on specially crafted packets that bypass the regular internet stack of your wireless adapter. This means that a program generates packets with whatever fields it needs and sends it to the driver (via the monitor interface) to be sent out even if the packet might not be compliant with the protocol used.

So, let's first test injection. To do this, we will need a monitor interface and aireplay-ng (part of aircrack-ng which you installed last time). You can optionally specify the channel you want to operate on when creating the mon0 interface:
Code: Select all
$ sudo airmon-ng start wlan0 6
$ sudo aireplay-ng -9 mon0

The program initially sends out broadcast probe requests. These are probe requests which ask any AP listening to respond with a description of itself. Not every AP will respond to this type of request. A list of responding APs is assembled to be used in subsequent steps. If any AP responds, a message is printed on the screen indicating that the card can successfully inject.

At the same time, any AP identified via a beacon packet is also added to the list of APs to be processed in subsequent steps. If a specific AP was optionally listed on the command line (BSSID and SSID), this is also added to the list of APs to be processed. Then for each AP in the list, 30 directed probe requests are sent out. A directed probe request is addressed to a specific AP. The count of probe responses received plus the percentage is then printed on the screen. This indicates if you can communicate with the AP and how well.

Figure 1 - Injection test

Closer look at open networks
We are going to take a closer look at how wireless networks operate under normal conditions by setting up an open network and sniffing its traffic. I've used a router to set up a test network called "NASA-HQ-Guests", because "FBI-Surveillance-Van-3" was already taken :)

In order to monitor a specific network you could use airodump-ng instead of Kismet (although both tools can do the same job). To list available networks and their clients you can run the following command (assuming your monitoring interface is already up):
Code: Select all
$ sudo airodump-ng mon0

You should see a list of networks with their ESSIDs (network name) and BSSIDs (AP MAC address) along with power, encryption type and channel. In our case we want to capture all traffic for the network with ESSID "NASA-HQ-Guests", which has a corresponding BSSID of "9C:C1:72:3A:5F:E1" and which operates in channel 1:
Code: Select all
$ sudo airodump-ng --write open-network-NASAHQ --output-format pcap --bssid 9C:C1:72:3A:5F:E1 --channel 1 mon0

For my tests I had my client (phone) connect to the wireless network and run the following commands:
Code: Select all
$ ping -c 3
$ ping -c 3 www.google.com
$ ping -c 3 www.hardkernel.com
$ wget -p http://www.hardkernel.com/main/main.php

The commands do some basic connectivity tests and simulate a browser loading up Hardkernel's main page (without any caches), and best of all, are repeatable. This generates about 10MB of traffic.

If we take a look inside the packet capture, several things may happen.

Scenario 1: You will see lots of management traffic, but little or no data traffic. This happened to me when I first tested and I struggled for a while to understand the cause. I suspected problems with modulation, interference from neighbors, directional/multipath transmissions, aliens - you name it. After many tests on the Odroid C1 with the Wifi Module 3, I tried the same test on a PC (with the same wifi card), and I was able to miraculously capture traffic! This means the most likely problem is the kernel/driver combination. I have tried to run the mainline kernel on the C1 to redo the tests but have failed so far. The Wifi Module 0 and Wifi Module 4 don't experience the same issues and allow you to capture traffic on the C1 without issues.

Scenario 2: You will see lots of management traffic and some data traffic. The amount of data traffic you see may vary based on your antenna position (relative to the AP and client), your current wireless interference pattern and possibly other factors as well. Based on some of my tests, surprisingly the Module 0 seemed to have fewer lost packets, but the tests I've ran were in the same room with the access-point, so I can't comment on the range you can get.

Here's the packet capture I made: https://github.com/mad-ady/wireless/blo ... p?raw=true. If you were to analyze it in Wireshark, you would find the following:
  • Packets 254, 256 and 258 represent IEEE802.11 Authentication and Association traffic
  • Once associated, the client makes DHCP requests to get an IP address (packets 268, 269). The complete DHCP transaction is not captured.
  • ARP traffic to find out the MAC address of the gateway (packets 431, 435)
  • ICMP Echo Requests to (packet 437). As you can see three pings were issued, but we were only able to capture one request and no replies.
  • DNS reply for a http://www.google.com query (packet 484)
  • ICMP Echo Reply for a ping to google (packet 486) and the second request (616), followed shortly by the third request (packets 627-629). You will notice that the requests packets have been retransmitted several times by the MAC layer. This is transparent to the layer 3 protocols, but may introduce additional latency/jitter.
  • DNS query for http://www.hardkernel.com - retransmitted 4 times (packets 638-641)
  • ICMP Echo Request to Hardkernel's IP (two packets out of three) (packets 728, 737, 738)
  • Finally, a DNS query and response for http://www.hardkernel.com (this time we ask (packets 814, 816)
  • HTTP traffic, starting with a three way handshake - only two packets captured (packets 818, 824) and a HTTP GET (packet 825)
  • HTTP traffic with a lot of retransmissions (e.g. packet 925, 927, 929, 931, etc.).
  • Dissociation from the WiFi network (packets 27219, 27223)
To do HTTP analysis in Wireshark, you can either find GET requests and use "Follow TCP Stream", or you can do bulk processing of all HTTP traffic by going into File -> Export Objects -> HTTP. Here you can see all the queries made and you can potentially extract data (such as images). Unfortunately if you try to save the site data you will find out that most of the images are corrupted and text is truncated. This is because the receiver was unable to pick up all the traffic on the wireless medium. This is quite different from what you're used from capturing from Ethernet - where collisions are avoided and the medium is usually reliable. Capturing traffic and a summary analysis can also show you what limitations you might face when trying to capture encrypted traffic so you'll know what to expect.

If you were to listen to an open network that doesn't have active traffic you will probably still see interesting things from active stations on the network. For instance you can expect to see some ARP traffic, NetBIOS broadcasts from Windows hosts, UPNP/SSDP multicast packets from DLNA devices such as media players or routers and even multicast DNS (port 5353) from Linux and Apple hosts that advertise their capabilities.

Even if you don't get much data, it can still be useful because you can analyse the user's requests and could potentially pick up unencrypted passwords and cookies sent with POST requests. I encourage you to browse the capture (or try capturing your own open network) and try to remember what can be seen next time you connect to an open network in a restaurant or airport!

Figure 2. Open network analysis

How network association works
Connecting to a wireless network involves the following steps (see figure 3):
  • A mobile station sends probe requests to discover 802.11 networks within its proximity. Probe requests advertise the mobile stations supported data rates and 802.11 capabilities such as 802.11n. Because the probe request is sent from the mobile station to the destination layer-2 address and BSSID of ff:ff:ff:ff:ff:ff (sometimes represented as "Broadcast") all AP's that receive it will respond.
  • APs receiving the probe request check to see if the mobile station has at least one common supported data rate. If they have compatible data rates, a probe response is sent advertising the SSID (wireless network name), supported data rates, encryption types if required, and other 802.11 capabilities of the AP.

    A mobile station chooses compatible networks from the probe responses it receives. Compatibility could be based on encryption type. Once compatible networks are discovered the mobile station will attempt low-level 802.11 authentication with compatible APs. Keep in mind that 802.11 authentication is not the same as WPA2 or 802.1X authentication mechanisms which occur after a mobile station is authenticated and associated. Originally 802.11 authentication frames were designed for WEP encryption however this security scheme has been proven to be insecure and therefore deprecated. Because of this, 802.11 authentication frames are open and almost always succeed.
  • A mobile station sends a low-level 802.11 authentication frame to an AP setting the authentication to open and the sequence to 0x0001.
  • The AP receives the authentication frame and responds to the mobile station with authentication frame set to open indicating a sequence of 0x0002.

    If an AP receives any frame other than a authentication or probe request from a mobile station that is not authenticated it will respond with a deauthentication frame placing the mobile into an unauthenticated and unassociated state. The station will have to begin the association process from the low level authentication step. At this point the mobile station is authenticated but not yet associated. Some 802.11 capabilities allow a mobile station to low-level authenticate to multiple APs. This speeds up the association process when moving between APs (roaming). A mobile station can be 802.11 authenticated to multiple APs however it can only be actively associated and transferring data through a single AP at a time.
  • Once a mobile station determines which AP it would like to associate to, it will send an association request to that AP. The association request contains chosen encryption types if required and other compatible 802.11 capabilities.

    If an AP receives a frame from a mobile station that is authenticated but not yet associated, it will respond with a disassociation frame placing the mobile into an authenticated but unassociated state.
  • If the elements in the association request match the capabilities of the AP, the AP will create an Association ID for the mobile station and respond with an association response with a success message granting network access to the mobile station.
  • Now the mobile station is successfully associated to the AP and data transfer can begin.
  • For WPA/WPA2 or 802.1X additional steps are taken after the association step before data is allowed to flow.
Figure 3. Authentication/association process

Even after a client is connected to an AP it continues to send probe requests, both to broadcast and also "directed" in order to discover new and potentially better access points in its vicinity. The directed probe requests contain the SSID of access points known to the client in hopes that the access point is nearby. Somebody listening on the wireless medium can use this to get a list of a client's trusted SSIDs and use them for tracking (https://youtu.be/5kiYszJ3ogo) or to set up "evil twin" access points.

The problem with hidden SSIDs

One way to try to protect a network is to hide the SSID. Most routers have an option so you can set your SSID to be "non-broadcasting". This means that the router still broadcasts beacon frames, but the frames will contain a blank SSID. Clients that want to connect to the network need to know the SSID in advance and send probe requests. This in theory is great - an attacker would have to guess a possibly hard SSID, but in practice it offers little protection - here's why.
When a client sends a probe request it will broadcast the SSIDs it knows about (including the hidden SSID of the access point). Anyone listening can pick it up (it's unencrypted even for encrypted networks) and can use it subsequently. It's not even too hard to expose hidden networks - airodump-ng does it by default.
Let's set up our network to be non-broadcasting and let's have airodump-ng listen on the traffic (only for Open networks in our case). You will notice that hidden networks are displayed typically as "<length: xx>" instead of SSID. As soon as a client is in the neighborhood (doesn't need to actually connect because it will be leaking directed probe requests), airodump will show you the network name - easy! All you have to do is wait.
Code: Select all
$ sudo airodump-ng -t OPN --channel 1 mon0

Figure 4. airodump fills in the SSID when it hears it

You can find out how this works by looking inside the packet capture (figure 5). For your convenience the capture with those three frames is available here: https://github.com/mad-ady/wireless/blo ... ealed.pcap

Figure 5. Packet analysis of hidden SSID connection

The problem with MAC access lists
Another favorite way of securing networks is by using MAC access lists on the access point. These specify which devices can connect to the network. Since the MAC address is unique and doesn't change, this gives the administrator control over which devices can join the network. An attacker would have to find out a valid MAC address and replace his own MAC to be able to join the network.
If this were a guessing game, in the worst case an attacker would need to go through all 2^48 addresses (probabilistically half would suffice). If it takes 2 seconds to test an address, it would take about 17 million years to go through all of them. If the attacker is not willing to wait that long, he might test with MACs of a particular vendor - such as Apple, Samsung, HTC, etc, in hopes of getting in faster. The first three bytes (24 bits) of a MAC address represent the vendor ID and a list of vendors can be downloaded from IEEE (http://standards-oui.ieee.org/oui.txt).
Code: Select all
$ wget http://standards-oui.ieee.org/oui.txt
$ grep '(hex)' oui.txt | grep -i Samsung | wc -l

Code: Select all
| Vendor  | Number of OUIs | Max search time (years) |
| Apple   |            471 |                     250 |
| Samsung |            398 |                     211 |
| LG      |            127 |                      67 |
| Lenovo  |             50 |                      26 |
| HTC     |             29 |                      15 |
| Xiaomi  |             26 |                      13 |

Even if it's still a lot of time, scanning one OUI (24 bits) takes a bit over 6 months. By speeding up the process (using multiple cards, narrowing down which OUI is still relevant) you could carry out an attack that might succeed in a number of months.

Clearly, this is not the way hackers get into your system. Let's see the faster option: listen for a MAC that has access. The simplest way is to use Kismet to listen to a network and see which clients are associated with it. If there's little activity you will need to wait for a while, but if it's a busy access point, the clients will be revealed instantly. Having a list of connected clients means you have a list of allowed MAC addresses, so your search is over - simple and fast! However having two devices with the same MAC on the same LAN is serious trouble, so in order not to break the network you can kick the real user off the network by sending him a bunch of deauthentication packets, as we'll see later.

But knowing what an allowed MAC is and having a device with that MAC are two different things. Luckily you can temporarily change the MAC address of a wifi adapter, either through GUI (NetworkManager) or through macchanger:
Code: Select all
$ sudo apt-get install macchanger
$ ifconfig wlan0
$ sudo macchanger --mac 88:30:8a:3f:44:b7 wlan0
$ ifconfig wlan0

Figure 6: Changing your MAC address

Up to this point we've explored mostly theoretical concepts of wireless networks. These will help you become a better network engineer, but you're not a haxtor yet. Now that the theory is behind us we can get to the 133t part :)

Achilles' heel: the deauthentication packets

There's a simple and guaranteed way to make trouble in your wireless neighborhood - start flooding the network with deauthentication packets. These frames signal to the access point that a client has left the network. There is no encryption and no protection mechanism around the frames, so anyone with a powerful enough transmitter can spoof these packets and cause the clients to be disconnected.
There are legitimate cases where this should be done:
  • WIPS - wireless intrusion prevention systems routinely send fake deauthentication packets in order to disconnect clients connected to other APs. This is to enforce a set of APs in a specific geographical area for certain businesses or government agencies (http://www.theruckusroom.net/2010/08/wh ... -hurt.html)
  • kicking the mother in law or kid off the network (ok, this probably can be done easier through your AP's management, but it's technically not illegal) :)
And illegitimate cases:
  • to reveal hidden SSIDs
  • to capture WPA/WPA2 handshakes by forcing clients to reconnect
  • perform Denial of Service attacks

To send a deauthentication packet you need only aireplay-ng:
Code: Select all
$ sudo aireplay-ng -0 10 -a 9C:C1:72:3A:5F:E1 -c 88:30:8A:3F:44:B7 mon0

The parameters are as follows:
-0 means deauthentication
10 - how many tries to make. Each try sends 64 packets to the client and 64 packets to the AP. Setting it to zero will keep sending deauth packets forever.
-a is the MAC address of the access point the client is connected to
-c is the MAC address of the client. If you omit it, aireplay will send broadcast frames to disconnect all clients connected to that AP. This is how you do a Denial of Service attack

Figure 7. Deauthentication attack

While aireplay is a powerful tool, there are even better tools available. For instance, if you install mdk3 (http://tools.kali.org/wireless-attacks/mdk3) you have the ability to disconnect all wireless clients from all visible access-points, or do other types of attacks, upsetting all your neighbors at once. To install it you have to download and compile it yourself:
Code: Select all
$ git clone https://github.com/wi-fi-analyzer/mdk3-master
$ cd mdk3-master
$ make
$ sudo make install

To disconnect every client that is connected to any access-point on channel 6 you could run the following:
Code: Select all
$ sudo mdk3 mon0 d -c 6

But wait, there's more! Mdk3 can also emit broadcasts for fake access-points. For instance, I've announced fake access points with WEP encryption on channel 11 that have random names. If this doesn't crash/slow down your neighbor's computers, it will at least baffle them when trying to connect to a new network. Note that the AP broadcast feature didn't work correctly with the Odroid Wifi Module 3, but worked great with the other two wifi modules.
Code: Select all
$ sudo mdk3 mon0 b -c 11 -h 11 -w -g

Figure 8. So many networks to choose from!

Visiting HardKernel's HQ
So far we've played with listening to wifi networks, kicking people off and testing transmission range. Now, let's try something more audacious - let's broadcast specific access-points and influence nearby devices to think they are in a different place. We're going to visit HardKernel's HQ in South Korea, buckle up!

Network based geo-location on mobile devices works by collecting the MAC addresses of your nearby access points and sending the data to a location provider service (typically Google if you're on Android). The location service looks up the list of MAC addresses in an internal database and reports back an approximate location. It's funny that network location doesn't rely on IP addresses at all - maybe because you could be connecting to the Internet through a series of tunnels and the end point could be far away geographically. What we're going to do now is generate enough access-points using mdk3 to fool the mobile device.

To extract access point information we can use wigle.net (https://wigle.net/search). Fill in the coordinates and click Search (search is available only for registered users). You can copy and paste the results in a text file. I tried two approaches, but the small area worked for me:

You can process this file and extract only BSSID and SSID:
Code: Select all
$ cat hardkernel-small.txt | grep 'infra' | sed 's/infra.*//' | sed -r 's/^map\s+//' | sed -r 's/\t/ /' > hardkernel-small-ssid.txt

In order for the attack to be successful, the victim needs to have network location active (set to WiFi - Battery Saving) and not have other location sources available. This means that GPS must be off (or no GPS satellites in view). If the device is in Airplane Mode it helps to keep the lock for longer, but it isn't mandatory. Wifi needs to be on and the victim needs to be able to access the internet to communicate with the network location service. Your typical victim can be a tablet without a 3G data connection.

To start broadcasting the networks use mdk3:
Code: Select all
$ sudo mdk3 mon0 b -v hardkernel-small-ssid.txt -g -t

You should see the networks appearing in your network list, but if you wait and wait some more… nothing seems to happen. I had Google Maps open on my phone and it stubbornly refused to move. This is because the new networks were conflicting in terms of location with the current networks in my area and the location service was confused and preferred to keep my current location. If you don't have many wireless networks around you, you could skip the next step.

In order to silence the networks around me we need something more drastic - a faraday cage. This is a metallic cage that shields out electromagnetic waves and can cut off wireless networks and 3G data. But how do you build a faraday cage out of household items? I tried with tin foil but it wasn't any good. I needed something stronger… Like a microwave oven! If I put my phone inside the microwave oven (with the power disconnected) and close the door, I could see that the network signal of available wifi hotspots would significantly decrease.

So, grab your odroid, power it from a power bank, start mdk3 and pop it into the microwave oven together with the victim's phone. Sounds like a horror story? Don't be alarmed, you unplugged the oven, right?

I left the phone and odroid inside for a few minutes and … nothing - I still had the same location on the map. But when I had given up and opened the oven door - a miracle! - the location jumped off to HardKernel's HQ. So, what happened? It turns out the wireless data connection I was using had failed as well (signal couldn't get through the oven) and the phone couldn't contact the location provider. But while it was "cooking", it had collected enough Korean access points that it firmly believed to be in the other location. More interestingly, the phone kept its location even when taken out of the faraday cage - it could still see the same access points and was a bit confused about the other ones around it, but preferred to keep the location until the Odroid stopped broadcasting.

Figure 9 - Messing with location

In light of the tests we've performed we can see that the wireless medium is far from secure even when using strong AES encryption. An attacker can easily disconnect any target and with sufficient disconnect attempts can force the target to connect to a different (spoofed) access-point. The attacker can now perform man-in-the-middle attacks against the victim, without the victim knowing. One method of defence against some of these attacks is the 802.11w standard (https://en.wikipedia.org/wiki/IEEE_802.11w-2009), which adds protected management frames, but it's not widely supported by all clients.

In terms of privacy, wireless networks are terrible. Every device will broadcast its known networks every few seconds even if you are connected to a network. To get around this issue, either delete the known networks from your wireless configuration or keep wifi off when not needed.

Hidden networks and MAC access lists are only effective if the network you're trying to secure is accessed very rarely - for instance your wifi in your holiday home could benefit from these settings. Otherwise they can be considered broken because they can be easily circumvented.

Services based on Wireless hotspots, such as location, are unreliable and could be easily spoofed. For instance, if your target's phone has programs like Tasker that run some actions based on location data (e.g. unlock the phone when near a specific AP) you could use a wireless attack to open up new attack avenues.
User avatar
Posts: 3331
Joined: Wed Jul 15, 2015 5:00 pm
Location: Bucharest, Romania
languages_spoken: english
ODROIDs: XU4, C1+, C2

Re: [Howto] Wireless injection using Odroid Wifi Modules

Unread postby Virtue Es » Sun Jan 28, 2018 7:15 am


I tried to do this on the Pi, but packet injection is really hard, especially if you have a weird chipset and no guidance.
I used Aircrack-ng, why do you use Kismet (i.e. what makes it better?).
Virtue Es
Posts: 5
Joined: Sun Jan 28, 2018 5:22 am
languages_spoken: english

Re: [Howto] Wireless injection using Odroid Wifi Modules

Unread postby mad_ady » Sun Jan 28, 2018 9:53 pm

There's nothing in particular that makes kismet better. It's just simpler to use at first and logs data to files by default.
Regarding injection - it really depends on the wifi chipset/driver. I couldn't get it to work with Odroid Module 3, but it worked with module 0 and 5.
User avatar
Posts: 3331
Joined: Wed Jul 15, 2015 5:00 pm
Location: Bucharest, Romania
languages_spoken: english
ODROIDs: XU4, C1+, C2

Return to Ubuntu (All Linux'es)

Who is online

Users browsing this forum: No registered users and 4 guests