#awesome-project

[comp6841lanceyoung]

Awesome Project - Collecting MAC addresses with two different devices from two different locations

So one of my main goals of this project was to successfully be able to collect an individual’s digital footprint from two different locations.

So by using all the techniques I had learnt thus far and my two devices, I was able to achieve my goal and prove that it could be done.

All the code that was used can be found here. These aren’t really necessary, but they definitely helped simplify the number of instructions I needed to remember for configuring and activating the capture.

After an hour or so of collecting data, and inputting that data into a postgres database, I was left with this:

A database of peoples probe requests during this time.

So demonstrate the significance of this, I’ve found a particularly interesting MAC address:

Here we can see at what time he walked into the Ainsworth Cafe, and then preceded into the K17 where he stayed. In addition, his device was advertising SSIDs which provide a small insight into the individual. Unfortunately, Wigle.net does not have any data on these SSIDs, but Wigle.net is community run. Organisations, like Google, with more resourcing might be able to use this data more effectively.

With more resources, you could map out a very large area, and be able to do a lot of data analytics on peoples movements, without individuals knowing.

[comp6841lanceyoung]

Inciting Live Connections with Devices - Advertising as Common Unencrypted SSIDs

So the idea here is to host a ‘fake’ AP using the most common free wifi SSIDs, inciting unconnected devices to automatically try and connect to my AP.

Here, we’ll be using a tool called ‘hostapd’. Unfortunately, I only have 1 wificard available, but fortunately, hostapd allows you host multiple APs from 1 single wifi-interface (using virtual interfaces). Though, just for the presentation, I’ll demonstrate a proof of concept with just 1 SSID. 

Using Wigle.net, I’ll get the top 3 most popular free wifi SSIDs:

FreeWifi

FreeWifi_secure (lol)

Guest

So, I’ll demonstrate it using FreeWifi. Here, we have a simple hostapd.conf file that looks as such: 

Which is picked up by my laptop:

So, when I was actually testing the idea on uni, an unknown device actually tried to connect to the AP:

Here, we can see that a device actually tried to send an association request. It’s unclear whether an individual clicked on it, or their phone automatically tried to connect, but regardless, the end result is the same.

So that was nice, but currently my fake AP does not implement DHCP, and hence, it cannot complete the connection as the device constantly waits to be allocated an IP. To implement DHCP, I can use `dnsmasq` and create a dnsmasq.conf file. Effectively, I need to allocate an IP in the subnet to act as the DCHP server and new devices will request and receive an allocated a unique private IP in the network so information (from the router) can be sent to said device (other device will receive the packets, but will ignore the packets as the destination address won’t match to their own).

[comp6841lanceyoung]

Collecting a Device’s Preferred Network List (PNL)

Generally, a device’s probe request will only contain a ‘Wildcard’ SSID meaning that the device is just looking to insight a response from any AP. This ‘Wildcard’ SSID isn’t incredibly useful as data. It’s only sometimes an actual SSID is sent with a probe, which is great information as one can build a potential profile of where said device has been in the past by doing an SSID look up on services such as Wigle.net.

But what if we were able to encourage the device to reveal information about said PNL? One possible method of attack is to implement some sort of dictionary attack where we emitted fake beacon frames or probe responses with fake SSIDs, inciting unconnected devices that have said SSID saved in their PNL to try and send authentication, or association requests to attempt to seek connection. Then, one can read the authentication, or association requests, and collect their MAC addresses along with the SSID they are trying to connect to.

So, first of all, where can we get a good enough dictionary?

Wigle.net contains a ranking of the most used SSIDs that they have collected. Hence, this could act as a pretty good foundation for a dictionary. However, as I want to prove this potential attack can work without bombarding the air with fake beacon frames, I’m going to just try a collection of potential Wifi’s available at libraries throughout Sydney - eg. ‘State Library of NSW’.

So, if a device responses to our fake library beacon frames, then we can say that said device has visited that library in the past. 

Obviously this doesn’t tell us much, but it can work just as a proof of concept - we may be able to get a sense of where the device lives as people would usually head to their local libraries.

So just by looking at my previously connected networks, I’ve identified 3 main formats:

<SuburbName> Library

<SuburbName>Library

Library of <SuburbName>

Now they have to be an exact match, and hence the difference between 1 and 2 is the space.

So, all that is needed is a list of suburb names of Sydney, which I’ll web-scrape from here.

Emitting Beacon Frames

To briefly explain beacon frames, beacon frames are management frames for access points (APs) to actively advertise their location to devices, meaning that a device can avoid sending and receiving probes and move straight onto authentication if it so desires (as the existence of the AP is known).

So, we can use a wifi-tool called mdk3 to flood the air with beacons.

Here, I’ve used the SSID ‘State Library of NSW’ as an example:

Therefore, one can implement the following strategy to collect more information from target devices:

Again, the value of SSID’s is one can use a tool, just as Wigle.net, to potentially build a profile of where they have been in the past.

Though, one flaw with this is that depending on how long SSIDs stay on the device list’s PNL, you have a very large window of when they potentially visited and used wifi at a particular site. It may be effective against tourists, though more the value in this was to familiarise myself with WLAN further.

[comp6841lanceyoung]

Legal considerations in collecting Wifi information - Case Study: Google Street View

In 2007, Google launched it’s Street View project where Google cars were tasked to drive around the world, collecting data to feed Google’s newest application, Google Street View. 

What wasn’t disclosed clearly was that Google cars also were collecting Wifi data. Investigations were conducted and Google was found not only collecting SSID’s and locations, but also they were intercepting and parsing information from the data section of unencrypted packets. 

This website provides a great summary of what has globally occurred and how each country has reacted. 

In Australia, an investigation was initiated under suspicion of breaking the law under the Privacy Act (1988). Later, the investigation was handed over to the Australian Federal Police, who were investigating whether Google has violated the Telecommunications Interception Act which “prevents people from accessing electronic communications other than for authorised purposes”.

It was found that Google had violated the Privacy Act - the Act does not empower the Commissioner to impose sanctions, but Google agreed to:

Publish an apology for Australia (Global apology)

Conduct a Privacy Impact Assessment (PIA) - unclear if internally done

Provide a copy of the PIA to the Commissioner’s Office

Consult regularly with the Commissioner about personal data collection activities arising from significant product launches in Australia

Collecting a huge Wifi map of Australia and huge amounts of unencrypted personal information vs. writing a blog, doing some sort of PR investigation and have chats will what seems like a powerless Commissioner.

Seems like a pretty good trade maen. 

The significant take away from this is that collecting wifi data is considered illegal in Australia, and hence, this project cannot be used outside academic research.

[comp6841lanceyoung]

Investigating 802.11 Protocols - Connecting to a Router

So I was able to actively capture the handshake between my Raspberry pi and my home network on wireshark:

So here, as I’ve mentioned in a previous blog, we have probe requests, establishing a ‘sense of existence’ to each other (router and device). After, we have the deprecated Authentication request, followed by an Association request. Finally, we have some Acknowledgements and shared key is established in a four-way handshake. 

Now this is just a one-sided perspective as it doesn’t contain the responses. With the responses, it would look as such:

So, going into the handshake in-depth was outside of my scope, but what I can take away is that every time a device connects with a router, the above steps will occur. Even if it is a remembered network (I turned off wifi and on again), all the steps occurred.

For this project, I will take advantage of the association requests, but this will be explained in another blog.

[comp6841lanceyoung]

Capturing MAC addresses from Probe Requests using Wireshark  - Big Data

Wireshark is a Network Analyser, and as I’ve previously mentioned, it has capture filters making it perfect to sniff probe requests and collect MAC addresses.

So by applying the following capture filter command, we can focus our data collection:

wlan type mgt subtype probereq

Meaning: only collect wifi packets that are ‘management’ packets, and of management packets, only collect probe requests.

So, the next thing we have to consider is Wireshark running out of virtual memory, especially if we’re collecting packets over a long period of time. Thankfully, Wireshark offers not only the ability to capture to a permanent file (avoiding the problem of running out of virtual memory) but also the ability to create new files or use a ring buffer (which would loop around through n number of files). These functions provide us with the method of effectively accumulate packets to then be stored into a postgres database for future convenience. 

Now the next problem is traversing wireshark data, which is stored in a .pcap file, into a postgres. Now for the moment, I’ll manually transfer the .pcap files onto my laptop (from the raspberry pi) and traverse it into a locally hosted postgres. This can be done using scp (file transfer via ssh) using a simple ethernet cable as the connection.

scp user@remote_host:remoteFilePath localFilePath

Once the files have been transferred onto my system, they then need to be converted into a simple .csv file to then be loaded into the database. Here, we’ll be using tshark. 

Now that we have the data in a .csv file with the time recording and the MAC address, we’re ready to input data into the database. We’ll be adding the location, as this information comes from the particular raspberry pi you’ve collected. In addition, I’ll be doing some pre-processing on the csv file by ‘squashing’ consecutive recordings of the same MAC address. And furthermore, I’ll make it a rule that one’s MAC address is at most recorded once a minute.

With this instruction set, I can successfully implement a live proof of concept by collecting data from two distinct places in close conjuncture with each other.

[comp6841lanceyoung]

Simple Database Design for collecting Data

The following is a simple relational model for a database that’ll I’ll be using to demonstrate the concept of collecting useful data from probe requests and other wifi techniques.

A device will be given a unique id and information collected from that point on from that device will be tagged with said id.

This provides a foundation for future data analysis.

[comp6841lanceyoung]

Setting up Alfa’s AWUS036ACH on a Raspberry Pi  3 Model B

So the Alfa AWUS036ACH uses the Realtek RTL8812AU chip set. Therefore, I need to install a driver to allow the kernel to interact with said chip set.

I’ll be using the following GitHub - so we’ll be essentially using a Kernel Module, which is defined to be code that can be dynamically loaded and unloaded from the kernel upon demand, all without the need to reboot the system. This is perfect for drivers, and hence, we’ll be loading a module using the Dynamic Kernel Module Support package (DKMS).

After following the instructions on the GitHub for the raspberry pi causes the wifi adapter to successfully register as a possible wifi-card to use in the wifi settings tab.

Once the driver has been installed, I’ll download the aircrack suite in order to be able to use some useful commands - so downloading the tar, installing the dependencies listed in the INSTALL files, and finally making should do the trick.

Now I can use the whole aircrack suite with my wifi adapter in monitor mode.