#awesome-project

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.

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.

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.

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. 

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.

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.

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.

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.