EMSEC

Don’t Trust Open Hotspots: Wi-Fi Hacker Detectionand Privacy Protection via Smartphone

Thomas Kropeit

Bachelor’s Thesis. March 1, 2015. Revised Edition.Chair for Embedded Security – Prof. Dr.-Ing. Christof PaarAdvisor: M. Sc. Christian Zenger

Abstract

Wi-Fi devices are increasingly ubiquitous in today’s world, and can perform the sameday-to-day tasks as a regular computer. Active wireless devices constantly transmitinformation, while trying to connect to a network. Capturing this data is trivial, butit is valuable to interested parties, for example marketing firms. This process happenswithout the user being aware of any data collection. However, the obtained informationcan be used to track their coarse location, and possibly to link them to different locations.

Many Metropolises have a city-wide coverage of wireless networks, with many beingprovided by individual companies. Most of these networks provide no cryptographicprotection, as accessing them is supposed to be easy and hassle-free. By trading securityfor ease of use, the users can be exposed to certain risks. Attackers can imitate thesenetworks and gain full control over the data sent by connected clients.

By analyzing the modus operandi of a device performing this attack, we were able tocreate a detection program. To counter the problem of unwanted Wi-Fi eavesdropping,we have developed an application that injects fake data to falsify the measurement. Asmartphone has been modified modified to interact with an external WLAN adapter,allowing it to run the devised applications.

A real-world measurement has been performed to analyze how many devices are affectedby this problematic. By our conservative estimate, between three and five percent ofsmartphone users can be affected by an evil hotspot. At the same time, almost everysecond we encountered divulged private information.

i

Statutory DeclarationI hereby declare that this submission is my own work and that, to the best of myknowledge and belief, it contains no material previously published or written by anotherperson nor material which to a substantial extent has been accepted for the award of anyother degree or diploma of the university or other institute of higher learning, exceptwhere due acknowledgment has been made in the text.

Eidesstattliche ErklärungIch erkläre, dass ich keine Arbeit in gleicher oder ähnlicher Fassung bereits für eine anderePrüfung an der Ruhr-Universität Bochum oder einer anderen Hochschule eingereichthabe.

Ich versichere, dass ich diese Arbeit selbständig verfasst und keine anderen als dieangegebenen Quellen benutzt habe. Die Stellen, die anderen Quellen dem Wortlaut oderdem Sinn nach entnommen sind, habe ich unter Angabe der Quellen kenntlich gemacht.Dies gilt sinngemäß auch für verwendete Zeichnungen, Skizzen, bildliche Darstellungenund dergleichen.

Thomas Kropeit

Table of Contents

1 Introduction 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Organization of this Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Fundamentals 52.1 Short Introduction into IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . 52.2 Practical Details of IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . 82.3 Network Auditing Software and Devices . . . . . . . . . . . . . . . . . . . 9

2.3.1 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3.2 Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4 Legal Obligations and Requirements . . . . . . . . . . . . . . . . . . . . . 12

3 Models and Assumptions 153.1 System Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2 Adversary Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4 Security Enhancing and Privacy Preserving Techniques 174.1 Karma: A Powerful Hacker Tool and Our Countermeasure . . . . . . . . 17

4.1.1 Technical Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.1.2 History of the Karma-attack . . . . . . . . . . . . . . . . . . . . . 184.1.3 Our Detection Program . . . . . . . . . . . . . . . . . . . . . . . . 20

4.2 The WLAN-Standard vs. Privacy . . . . . . . . . . . . . . . . . . . . . . . 214.2.1 Tracking, Metadata and Other Information for Free . . . . . . . . 214.2.2 SSID-Mixer: Privacy Protection for Everyone . . . . . . . . . . . . 21

5 Testbed Implementation 255.1 Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.2 Technical Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.2.1 Building and Testing Environment . . . . . . . . . . . . . . . . . . 265.2.2 Compiling Android OS and Kernel Modifications . . . . . . . . . . 275.2.3 Device Initialization and OS Installation . . . . . . . . . . . . . . . 305.2.4 Demo Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.3 Android Application “WifiAnalyzer” . . . . . . . . . . . . . . . . . . . . . 325.3.1 General Presentation . . . . . . . . . . . . . . . . . . . . . . . . . . 325.3.2 Defensive Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 34

iv Table of Contents

5.3.3 Testing the Application . . . . . . . . . . . . . . . . . . . . . . . . 365.4 Monitored Hotspot via Command-line Interface . . . . . . . . . . . . . . . 37

6 Evaluation & Results 396.1 Current State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396.2 Countermeasure Performance . . . . . . . . . . . . . . . . . . . . . . . . . 42

7 Conclusion 437.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

A Appendix 45A.1 Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45A.2 Important Commands for Adb and Fastboot . . . . . . . . . . . . . . . . . 47A.3 Code Excerpts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48A.4 SQL Commands Used for Data Processing . . . . . . . . . . . . . . . . . . 50

A.4.1 Queries used for Evaluation . . . . . . . . . . . . . . . . . . . . . . 52A.5 Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54A.6 Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

List of Algorithms 56

List of Figures 57

List of Listings 58

List of Tables 59

Bibliography 61

1 Introduction

Over the last decade, mobile devices and especially smartphones have evolved from aniche product to an omnipresent medium. More than 320 million smartphones have beenshipped worldwide in the third quarter of 2014, an amount which is 25% larger thanin the year before1. Spending a day without accessing the Internet is unthinkable formany people. As a result, most devices keep a permanent Internet connection, whetherit is actively needed or not. This development has been picked up by various shops andrestaurants, as they now offer free Wireless Local Area Network (WLAN) access for theircustomers. While many gladly use the provided service, many users may not be ware ofthe possible risks involved. One of these risks is the eavesdropping on wireless clients.

In this chapter, we describe our motivation to examine these risks and give exampleshow virtually everybody is affected by them. The chapter continues with a presentationof the related research on this subject. Two applications were developed for this thesis.One to identify possible WLAN attacks and one to preserve the privacy of WLAN users.Both are briefly described at the end of this chapter.

1.1 MotivationThere are risks associated with Wi-Fi one should be aware of. A wireless device which issearching for active networks creates metadata. Amongst these information is the devicesunique address, and sometimes the name of the requested network. This is valuableinformation for marketing purposes, as it can be used to calculate a customers duration ofstay, and their coarse location inside the store can be triangulated. However, many usersmay not be aware that they are being, and hence this may be done even against theirown will. As this process can be done passively, affected users have no chance to find outif their devices are monitored. It is the topic of this thesis to assess the availability ofthis form of user data at three public locations in the city of Bochum, and to investigatewhether even further information can be extracted. Some monitoring solutions whichuse the above-mentioned mechanism to track user data from smartphones have gainedlarge media attention. In August 2012 “smart bins” have been installed in London, bya startup company that sells advertisements. These bins have been placed at variousshopping streets to collect the “proximity, speed, duration and manufacturer” of eachpassing device2. However, city officials have asked the firm to remove the bins on the

1http://www.idc.com/getdoc.jsp?containerId=prUS25224914, as of March 1, 2015 – Study on thesmartphone market shares, and shipped units by the International Data Corporation (IDC).

2http://www.independent.co.uk/life-style/gadgets-and-tech/news/updated-londons-bins-are-tracking-your-smartphone-8754924.html, as of March 1, 2015 –News article on the “smart bins” in London by the newspaper “The Independent”.

2 1 Introduction

next day, not by citing the law but by arguing that such data collection “needs to bedone carefully, with the backing of an informed public”.

In order to extract user data from smartphones, the metadata send from the devicessearching for availible WiFi networks needs to be intercepted by specific, external devices.An adversary that chooses to actively interfere with the devices network connection candirectly harm the user. A popular attack called “Karma” creates a prepared hotspot,that vulnerable devices may automatically connect to. A successful connection is fatalto the smartphone user as the adversary possess full control over the devices wirelessconnection. He may choose to view, to suppress, or even to modify incoming or outgoingtransmissions. Fortunately, this attack today only works to a limited extend, as theglobal use of encryption on WLANs has been increasing rapidly over the last years.3.

1.2 Related Work

Plenty of research has been conducted in the area of wireless security. One of thekeystones for this thesis is the work from Dai Zovi et al. in 2004 [DZM05]. Theyproposed the powerful “Karma-attack”, which allows an attacker to establish himself asa Man-in-the-middle (MitM) between the victim and the Access Point (AP). Even after adecade the attack is still viable, the latest improvement is shown in [IdV14]. Bauer et al.focused on detecting these networks in [BGM08], by comparing the context of availableAPs when connecting to a network. Additionally they proposed a new authenticationmethod for WLAN based upon the concept of “trust-on-first-use”.

The problem of passive divulgement of data on wireless devices has been the focus ofnumerous publications. A fundamental comparison which devices relinquish personalinformation has been conducted in [DW14]. Further research demonstrates how theseinformation can be used to create profiles. Cunche et al. captured WLAN traffic at publicplaces in [CKB12]. They analyzed the requested networks from Probe Requests (PReqs)of different devices and used this data to infer social links and behaviors between thedevice owners. Barbera et al. conducted a similar, but more extensive experiment in[BEM+13]. During a threee-month campaign they placed monitoring devices at trainstations, malls, universities, in city tours and at national events. Cheng et al. improvedthe analyzing techniques by calculating spatio-temporal co-occurrences, the probabilitythat two users reside at the same time and place in [CMC+12]. An improved monitoringset-up was demonstrated by Musa et al. [ME12]. They were able to track wirelessdevices inside cars by placing multiple antennas at an cross-way and calculating thevehicles trajectory. Cunche also showed how one can identify a persons mobile device byselectively broadcasting networks to previously captured PReqs in [Cun13]. Greensteinet al. demonstrated multiple privacy problems of WLAN in [GGP+07]. For instance,a company that runs a large public WLAN can create a movement profile of its users.Using this data, one can easily track whether employees on sick leave are moving aroundthe city.

3https://wigle.net/stats, as of March 1, 2015 – Statistics on the usage of WLAN encryption by theonline database WiGLE.

1.3 Contribution 3

1.3 ContributionThis thesis continues to analyze the impact of information leaks through wireless devices.Wireless traffic was captured at three different public locations and it is analyzed if thetrend of devices using more privacy-friendly implementation is yet noticeable. Furthermoretwo applications for privacy preservation and security enhancement are presented. TheSSID-Mixer can be used to inject fake data and thus tamper with an unwanted Wi-Fievaluation. The second application, the Karma-Detector, can detect evil APs usingthe “Karma-attack” by “challenging their feature” to create every requested network.Both applications do not require a computer or laptop, and can be used on an Androidsmartphone.

1.4 Organization of this ThesisThe content of this thesis can be divided into two sections. Chapter 2 begins with thetechnical background, which includes a short introduction into the WLAN standards,an overview of current network auditing software and devices, as well as a summary ofrelevant laws for conducting this research in Germany. Chapter 3 continues with thesystem and adversary models. As mostly devices using so called directed PReqs, whichdivulge the name of the requested network, are susceptible to the Karma attack. For theadversary, we consider one using three increasingly powerful attacks, with the strongestbeing the Karma attack. In Chapter 4 the two devised applications are introduced.This include the Karma-Detector to identify an ongoing Karma attack and the SSID-Mixer to falsify the results of WLAN eavesdroppers. Within the second part of thisthesis, Chapter 5 describes how an Android smartphone is modified to capture packetsusing an external antenna. Furthermore, an Android application, that implements bothapplications, Karma detector, and SSID-Mixer, is described in Section 5.3. A real worldevaluation of the traffic captures is shown in Chapter 6. Chapter 7 concludes the thesiswith a summary and an outlook on future work.

2 Fundamentals

This chapter introduces the current wireless standards and practical details on the dailyuse while keeping a researchers point of view. Furthermore, different software-suites anddevices used for network audition are presented. This chapter concludes with a summaryof the legal obligations affecting the research of this thesis.

2.1 Short Introduction into IEEE 802.11

The 802.11 protocol for wireless data transmission, developed by the Institute of Electricaland Electronics Engineers (IEEE), defines Wireless Local Area Networks (WLANs) forthe communication between wireless devices (“stations”). It was first released in June1997, and allowed transmission rates of up to 2 Mbit/s (IEEE 802.11, [Rec, Section 1.2.2]).Subsequent versions of the standard can be identified by one or two trailing alphabeticcharacters (e. g. 802.11b, 802.11g, 802.11n, 802.11ac). The first versions are using afrequency of 2.4 GHz, which is split into 14 different channel, with each channel being5 MHz apart. However, due to different national regulations, some channels may not beused. In Europe, these regulations are specified by the European TelecommunicationsStandards Institute (ETSI). It is permitted to use the channels 1 through 13 on the2.4 GHz spectrum (EN ETSI 300-328).

Using multiple antennas, 802.11n can achieve transfer speeds of up to 600 Mbit/s, while802.11ac can even exceed 1 Gbit/s. In addition to a frequency of 2.4 GHz, 802.11n uses afrequency of 5 GHz, while 802.11ac only utilizes the latter. WLANs are compatible towired connections using Ethernet, and in many networks a combination of both protocolsis used. Wireless devices are sometimes referred to as “Wi-Fi ready”, Wi-Fi is a trademarkused to mark devices compliant to IEEE 802.11 networks1. Wi-Fi is not an abbreviationfor “Wireless Fidelity”, this misconception originated from an early marketing slogan:“Wi-Fi – The Standard for Wireless Fidelity”2.

Wireless Access Points (APs) are usually identified by their Service Set Identification(SSID), which is basically the name of the network, for example, “eduroam” or “RUB-WiFi”. The SSID is a string of up to 32 characters and is usually encoded using 7-bitASCII. Each station, both clients and APs, is identified by its unique Media AccessControl (MAC) address.

Similar to the wired transmission via Ethernet, WLAN splits the transferred datainto packets. These packets can be divided into three different types: Data, Control

1https://en.wikipedia.org/wiki/Wi-Fi, as of March 1, 2015 – Wikipedia article on Wi-Fi.2http://boingboing.net/2005/11/08/wifi-isnt-short-for.html, as of March 1, 2015 – Blog article

“WiFi isn’t short for Wireless Fidelity”

6 2 Fundamentals

and Management. Data frames contain datagrams of upper layers in the Open SystemsInterconnection (OSI) model. Control messages contain information on traffic control,which may be used for collision avoidance. The third type, management frames, is usedduring network discovery and association. It is the most relevant type for this thesis.

There are three steps in the connection process, (i.) the discovery phase, (ii.) authenti-cation, and (iii.) association, which will be introduced in the following paragraph. Thereare two standardized modes of network discovery: passive and active scanning. In passivemode, the client solely relies on the packets send by APs, while in active mode requestsare sent by the client. In practice, both modes are used in parallel.

We will introduce some of the management frames in detail as their functionality isrelevant later on:

Beacon frames are sent by APs to announce the presence of a network. They containinformation on the technical capabilities of the AP, for example its supportedtransmission rates, and the utilized encryption mode. Beacon frames are sent ina fixed interval, usually every 100 ms [Rec, Section 9.7.8], to ensure that activedevices receive the message.

Probe Request (PReq) frames are sent by wireless clients to check for available net-works. There are two different modes: directed and broadcast. Directed PReq“ask” for available networks by specifying their SSID, multiple requests are sent ifthe device checks for multiple networks. Broadcast PReq work differently – only asingle request is sent and every network in range is expected to respond. Comparingthese modes, the directed PReq can leak greater amounts of private information,as multiple SSIDs may be used to connect a person to different locations. Eventhe persons occupation may be roughly determined (see [BEM+13] and [CKB12]).Figure 2.1 shows an example of both modes.Both, the scanning interval and the mode varies across modern mobile devices[DW14].

Probe Reponse (PResp) frames are the counterpart of PReqs and behave very similarto beacon frames. In fact, most of their content is identical to a beacon frame,however they are only sent to the client and only if it is compatible to the AP3.

Deauthentication (DeAuth) frames are sometimes sent by APs to forcibly terminate aconnection. Using specialized software (see Section 2.3.1), it is possible disconnectarbitrary devices by forging and injecting the frame.

Beacons and probes are used during the network discovery phase, when a client islooking for networks. Once a compatible network is found, an authentication request issent. This request includes, if applicable, the security configuration. Otherwise it is aNULL function. The latter is automatically accepted within the authentication response,otherwise the password has to be validated. During the last step, the association, the

3Some manufacturers include specific parameters into the frame, theses values vary between differentmodels and clients.

2.1 Short Introduction into IEEE 802.11 7

Probe Request

[SSID=null]

Probe Response

[SSID=AP1]

Probe Request

[SSID=null]

Probe Response

[SSID=AP2]

(a) Broadcast Probe Request

Probe Request

[SSID=AP1]

Probe Response

[SSID=AP1]

(b) Directed Probe Request

Figure 2.1: Comparing Broadcast and Directed Probe Requests4.

client repeats the SSID and his supported data rates. If the AP accepts the request, anassociation response is sent, concluding the process as shown in Figure 2.2.

Active/Passive Scanning

Authentication Request

Authentication Response

Association Request

Association Response

Figure 2.2: The WLAN authentication and association process4.

4Figures 2.1a, 2.1b and 2.2 are inspired by “H3C WX Series Access Controllers Web-Based ConfigurationManual”, Chapter 7. (http://www.h3c.com/portal/download.do?id=828185, as of March 1, 2015)

8 2 Fundamentals

2.2 Practical Details of IEEE 802.11

Most details of IEEE 802.11 are defined in the respective protocol versions and amend-ments. However, some implementation details are not specified and left for the manufac-turers to implement. Other details, for example the mode of operation of the wirelessinterface, are not unique to WLANs and as a result not explicitly specified in IEEE802.11.

A wireless device can be used in different modes, mainly managed, promiscuous andmonitor : Managed mode is the default state, it allows clients to connect to a WLAN.In promiscuous mode the client is also required to connect to a network, however alltransmitted packets can be processed, including those intended for other clients. Thethird mode, monitor, is similar to promiscuous mode, but it is not restricted to a singlenetwork. Every received packet, independent of the originating network, can now beprocessed. However those packets which originate from an encrypted network, and canonly be partially read. In practice, monitor mode is often preferred over promiscuousmode as it processes more data, and is compatible with more devices. However, onecan only capture data on one channel, as the interface is fixed to a single frequency.One way to circumvent this is “channel hopping”. Using this technique, the devicesautomatically changes its channel in a predefined interval, which is typically between 200and 250 ms [Rec, Section 4.6.1]. This is useful to create an overview which channels arecurrently in use. However, this prevents the capture of continuous data transfers, as thecapture-process is likely to be interrupted by switching the channel.

Given that some WLANs have to cover a large area, for example company-widenetworks, it is important that devices can seamlessly transition between multiple APs.This can be achieved through WLAN roaming. The technical implementation of roaming,i. e., on which condition the client should change the AP, are not defined in the 802.11standard [Rec, Section 2.3]. However, all APs have to be configured identical on allsettings, excluding the frequency. The latter is not a mandatory requirement, but itis advisable to reduce interference. This is sufficient, as client devices identify WLANssolely on their SSID, the APs MAC address is ignored. On consumer networks, i. e.,WLANs using a Pre-Shared Key (PSK), the authentication and association process isnot abbreviated. The only advantage is a reduced configuration effort. On enterprisenetworks, which use an authentication server, only a re-association is required as thedevice is already authenticated to the server.

Another important aspect is that management frames, in many cases, provide noauthenticity. As a result beacon, PReq, PResp, DeAuth and other frames can be forged.This means that an attacker can create and send these frames using arbitrary content.Sending a large amount of these packets can result in a Denial of Service (DoS) attack.The issue becomes most clearly in the context of DeAuth frames. An attacker mayforge these frames and disconnect clients at will. The aim of the task group 802.11wis to resolve the issue of spoofed management frames by adding a Message IntegrityCode (MIC). The required shared secret is derived by an additional 4-way handshake.Unfortunately the standard is not widely supported, and the corresponding task group

2.3 Network Auditing Software and Devices 9

has not updated the draft since May 20095.

2.3 Network Auditing Software and DevicesDifferent tools and software suites, both those used for basic network configuration andthose used for network auditing or penetration testing, rely on basic configuration toolsto manipulate the wireless interface. This section explains the configuration tools first,continued by popular security tools, e. g. those used for packet capture. The sectionfinishes with a presentation of a popular embedded device which has a selection of securitytools preinstalled.

2.3.1 SoftwareWireless configuration tools are used by the Operating System (OS) to control the wirelessinterface, for example, to scan for available networks or to connect to a specified network.The following security applications and software-suites can be used for both defensiveand offensive purposes. Software-suites are a collection of related applications, often inthe form of a specialized Linux distribution.

Configuration

The prevalent tools for wireless device configuration on Linux based OSs are iw6 andthe Wireless Tools software-suite7, which includes, amongst others, iwconfig, and iwlist.Both tools, iw and iwconfig, serve the same purpose: modifying wireless interfaces andconnecting to WLANs. However they are implemented slightly different, which resultsin a varying syntax. Both tools may be used independently, though it is useful to haveboth at hand as some third-party-software can only use one of them.

Security Tools

The aircrack-ng suite8 is amongst the most popular wireless network auditing softwares. Itis well known for its homonymous tool aircrack-ng, a software designed to crack encryptionkeys of WLANs using Wired Equivalent Privacy (WEP) and Wi-Fi Protected Access(WPA). Amongst many other tools, the suite contains airodump-ng, and aireplay-ng,which are used for packet capturing and injection.

Another important tool for packet capturing is (lib)pcap9. It is not an application byitself, but a library which may be used by other applications. One of these applications

5http://grouper.ieee.org/groups/802/11/Reports/tgw_update.htm, as of March 1, 2015 – Statusof the IEEE 802.11w Task Group.

6http://wireless.kernel.org/en/users/Documentation/iw, as of March 1, 2015 – Offical documen-tation of iw.

7http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html, as of March 1, 2015 – Offi-cal homepage of the Wireless Tools for Linux.

8http://www.aircrack-ng.org/doku.php, as of March 1, 2015 – Offical homepage and documentationof aircrack-ng.

9http://www.tcpdump.org, as of March 1, 2015 – Offical homepage of libpcap.

10 2 Fundamentals

is tcpdump, a Command-line interface (CLI) tool by the same developers. Section 5.2describes how it can be used to implement a rudimentary packet sniffer.

The final application, which has been used extensively during our research, is Wire-shark10. Similar to tcpdump, and also based on (lib)pcap, it is a network protocol analyzer,though it comes along with a Graphical User Interface (GUI). Amongst other usefulfeatures, Wireshark offers extended filtering capabilities. This is crucial while analyzingnetwork traffic to reduce the number of packets and to identify relations between them.

Figure 2.3: The Wireshark user interface in “live capture”-mode.

The scanning interface of Wireshark as shown in Figure 2.3 lists captured packetswith columns of the most important information: timestamp, source MAC address,destination MAC address, transmission protocol, length, information on packet content,and, if applicable, the Received Signal Strength Indicator (RSSI) value.

Above the packet list is the aforementioned filter menu, and below are the selectedframes contents. For example, one may enter the filter wlan.fc.type eq 0 to onlyshow WLAN management frames. Further useful filters are described in the Wiresharkdocumentation and wiki11. The frame details are shown in two versions: human-readablewith information on the meaning of each string, and in byte-form – the way it is send10https://www.wireshark.org, as of March 1, 2015 – Offical homepage of Wireshark.11http://wiki.wireshark.org/DisplayFilters, as of March 1, 2015 – Display Filter Guite for Wire-

shark.https://www.wireshark.org/docs/dfref/w/wlan.html, as of March 1, 2015 – Wireshark DisplayFilter Reference on WLAN.

2.3 Network Auditing Software and Devices 11

through the network.

Software Suites & OS Distributions

Several Linux distributions focus on security tools, and combine different applicationsinto one large software-suite. Amongst the most popular distributions is Kali Linux12,previously known as “BackTrack”. It describes itself as “the most advanced penetrationtesting distribution, ever.”13, and includes tools for many areas, for example InformationGathering, Vulnerability Analysis, Wireless Attacks, Sniffing/Spoofing, Reverse Engineer-ing, and Digital Forensics14. While Kali was originally created for x86-based computers,there are versions available for other processors and devices, for example low pricedsingle-board computer like the Raspberry Pi15. A specialized version for Android devices,“Kali NetHunter” was released in September 201416.

While Kali is a Debian-based distribution, there are similar OSs available, for example,“Backbox” (based on Ubuntu) and “BlackArch” (based on Arch Linux).

2.3.2 Devices

Lately, embedded devices have become very popular for personal use. They are usuallypowered by an inexpensive single-board computer like the Raspberry Pi. It is availablefor less than 50e, and as of February 2015, 5 million units have been sold17. The originalidea behind the project is to see “affordable, programmable computers everywhere”18.Since the release of the first version in February 2012, it has been the basis for manydo-it-yourself projects, for example servers for home automation or file storage, homemedia centers, or even building a robot19 Thus it is not surprising to see network devicesrunning on similar hardware, one of them is presented in the following paragraph.

The WiFi Pineapple is a custom WLAN router designed by Hak520 and based onthe OpenWRT21 OS. While earlier versions were an off-the-shelf router with a customfirmware, the latest version “Mark 5 (MKV)” is a custom design (see Figure 2.4). It offerstwo distinct wireless antennas and an ethernet port. It is available for 100e and targetstechnical enthusiasts rather than IT-Professionals. The installed software is similar toKali Linux, but it has been reduced to those applicable for network auditing, for example12http://www.kali.org/, as of March 1, 2015 – Official hompage of Kali Linux.13This quote is shown on the official hompage, http://www.kali.org/14As seen in the Kali Linux main menu.15http://www.raspberrypi.org/, as of March 1, 2015 – Offical homepage of the Raspberry Pi computer.16http://www.nethunter.com/, as of March 1, 2015 – Offical homepage of the Kali NetHunter distribution

for Android devices.17http://www.raspberrypi.org/five-million-sold/, as of March 1, 2015 – Official announcement on

the Raspberry Pi homepage – “FIVE MILLION SOLD!”.18http://www.raspberrypi.org/about/, as of March 1, 2015 – About us – The Making of the [Raspberry]

Pi.19https://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/robot/, as of March 1, 2015 – Uni-

versity of Cambridge – “Physical computing with Raspberry Pi”.20https://wifipineapple.com/, as of March 1, 2015 – Official homepage of the WiFi Pineapple.21https://openwrt.org/, as of March 1, 2015 – Official homepage of the OpenWRT project.

12 2 Fundamentals

DNSSpoof to manipulate DNS Requests, SSLStrip to “decrypt” SSL/TLS-encryptedtraffic, and small tools like urlsnarf which automatically extracts the address of websitesvisited by clients.

Figure 2.4: Hak5’s WiFi Pineapple Mark V22

One of the Pineapple’s main features is the “Karma” attack, by using it, the Pineapplebecomes a “Wi-Fi honeypot”. It creates an open network, and gets clients to automaticallyconnect by sending spoofed beacon and PResp frames for the SSIDs requested by stations.Once a connection has been established, the attacker can both capture and manipulatethe traffic. The attack is explained in detail in Section 4.1.

There is another feature called “Reconnaissance Mode”. It is a sniffing application thatanalyzes the wireless traffic to show active APs and both associated and not associateddevices, including information like the Extended Service Set Identifications (ESSIDs) (theAPs MAC address), signal strength, channel, and encryption type. A similar applicationfor Android devices is shown in Section 5.3.

2.4 Legal Obligations and Requirements

Conducting research in the area of offensive security requires at least a basic understandingof the respective laws. In Germany this applies to §202 a–c and §303 a,b Strafgesetzbuch(StGB) (the German penal code). The latter, §303a “data modification”, and §303b“computer sabotage” can be disregarded in the context of this thesis as they deal withthe damage dealt after breaking into a system.

22https://hakshop.myshopify.com, as of March 1, 2015 – Image source for Figure 2.4.

2.4 Legal Obligations and Requirements 13

More relevant are §202a “data espionage”23, §202b “data interception”24 and §202c“preparing the espionage and interception of data”25. The last paragraph is colloquiallyknown as the hacker paragraph, as it deals with security software. It includes a ratherunspecific, rather general passage stating that obtaining, selling or otherwise distributingsuch software is punishable as a criminal offense. This is problematic as most of thesecurity software used by IT professionals, e. g., penetration tester, falls into this category.A constitutional complaint has been denied26, arguing that using dual-use software is notcriminal by default, especially if its use is authorized by the affected person or company.

§202b StGB explicitly states that only non-public transmissions may not be eaves-dropped upon. Hence it is not prohibited to eavesdrop on public communications likemanagement frames. Thus allowing the public survey of this thesis, which will be evalu-ated in Chapter 6. However, using a program for offensive purposes can be consideredillegal, if it is done in public and not in a controlled environment.

23http://dejure.org/gesetze/StGB/202a.html, as of March 1, 2015 – §202a StGB.24http://dejure.org/gesetze/StGB/202b.html, as of March 1, 2015 – §202b StGB.25http://dejure.org/gesetze/StGB/202c.html, as of March 1, 2015 – §202c StGB.26https://www.bundesverfassungsgericht.de/pressemitteilungen/bvg09-067.html, and https://

www.bundesverfassungsgericht.de/entscheidungen/rk20090518_2bvr223307.html, as of March 1,2015 – Press release and court decision on the constitutional complaint against §202c StGB.

3 Models and Assumptions

In this thesis we will assume different models for systems and adversaries. Both aredescribed in more detail below.

3.1 System Models

The system model deals with wirelessly communicating devices applying the IEEE802.11 standard. This standard is the widely established in virtually every notebook orsmartphone.

Numerous of those devices have been connected to a cryptographic unprotected (oropen) wireless network at some point in the past. After that, this network is usuallystored in the Preferred Network List (PNL) on the device. To put this statement intoperspective: There are many places providing open and public networks, including coffeeshops, train stations and airports.

A large amount of devices are using so called directed PReqs. However, using this typeof PReq makes the device vulnerable to the “Karma attack”. This attack is known for adecade, and is explained in detail in Section 4.1 and [DZM05]. A secure alternative isavailable in the form of broadcast PReqs. After a device is revealing their requested SSIDsto a potential attacker, the connection state of the device doesn’t matter. Therefore, thesystem model considers devices connected or unconnected to secure or open WLANs.

3.2 Adversary Models

Regarding adversaries, we differentiate between active and passive attackers [SCW+11].A passive attacker, colloquially named Eve, is able to eavesdrop on all wireless datatransmissions. This allows Eve to detect active wireless devices, and to identify themas an AP or client by comparing the received management frames. It is also possible todistinguish between devices which communicate only with the AP, and devices whichcommunicate with another client as well.

An active attacker, known as Oscar, can actively manipulate data transmissions byintercepting and injecting packets. We also consider an attacker who can manipulatethe physical addresses (e. g., MAC address) on his device. Furthermore the attacker caninterrupt established WLAN connections between an AP and a client by injecting socalled DeAuth packets. He may use this ability for a MitM attack. We consider three

16 3 Models and Assumptions

versions of this attack, which are increasingly more powerful:

1. The attacker creates an open wireless network with a single, fixed SSID. He cannotchoose the SSID automatically by processing PReqs, however he may choose apopular SSID (e. g. Starbucks or Telekom) on creation.

2. He extends the first version by using DeAuth frames to disconnect clients fromtheir AP, intending them to connect to his own AP.

3. The attacker executes the “Karma-attack”. By automatically processing PReqs,he can automatically create the corresponding network. Combining Karma withDeAuth creates a powerful attack that will effect many clients.

We do not consider hardware modification or denial of service (DoS) attacks.

4 Security Enhancing and PrivacyPreserving Techniques

In this Chapter the technical details of the Karma-attack and a tool to detect an attackerusing it are introduced. Furthermore the problem of unwanted WLAN eavesdropper isexplained. A second tool to counter this attack by injecting fake data is presented.

4.1 Karma: A Powerful Hacker Tool and Our Countermeasure

This Section describes the Karma-attack. Firstly the technical details, and whichbehavior is exploited for a successful attack are explained. The Section continues withthe historical enhancements from different authors and concludes with a defensive toolagainst the attack, the Karma Detector.

4.1.1 Technical Details

Karma is an active attack against WLAN clients. This means that an attacker has toactively manipulate wireless traffic. The attack itself exploits the careless behavior ofmany devices, of using directed PReq instead of broadcast PReqs, allowing an attackerto monitor the requested SSIDs from active devices. Using Karma, the attacker auto-matically sends beacon and PResp frames for every PReq and directs the clients to hisown network (see Figure 4.1). In other literature this attack is sometimes referred to as“Evil Twin”-attack or Rogue AP, although the latter usually implies a non-authorizedAP, which is not necessary with malicious intent.

A successful Karma attack results in the attacker having full control over the victimsWLAN interface. He may choose to view, to suppress, or even to modify incoming oroutgoing transmissions. Karma is successful because many user keep open networks intheir devices PNL. As defined in Section 3.1, we only regard devices with this behavior.It is important to note that Karma only works on unencrypted networks, as one cannotcreate a faked, encrypted network without knowing its passphrase (PSK)1.

Furthermore, the attack can be enhanced by combining it with Deauthentication(DeAuth) packets. An attacker may force the client to disconnect from their currentnetwork, intending them to reconnect to his own network. This can be achieved by usingthe application aireplay-ng. One can disconnect either a specific or every client of a singlenetworks, as seen in Listing 4.1.

1[IdV14] demonstrated how one can automatically crack the PSK of some authentication variants.However, their attack underlies certain restrictions.

18 4 Security Enhancing and Privacy Preserving Techniques

Probe

Req

uest

[SSI

D=Te

leko

m]

Probe

Respo

nse

[SSI

D=Te

leko

m]

ProbeRequest

[SSID=RUB-W

iFi]

ProbeRequest

[SSID=RUB-W

iFi]

Figure 4.1: Schematic representation of the Karma attack.

1 Syntax for deauthencating a single client:2 # aireplay-ng --deauth $deAuthCount -a $AP-MAC -c $Client-MAC $nic34 Syntax for deauthenticating every client of an Access Point:5 # aireplay-ng --deauth $deAuthCount -a $AP-MAC $nic67 Example command and output:8 # aireplay-ng --deauth 1 -a 00:1E:E5:63:F1:A0 -c BC:F5:AC:F6:30:50 wlan19 10:10:26 Waiting for beacon frame (BSSID: 00:1E:E5:63:F1:A0) on channel 6

10 10:10:27 Sending 64 directed DeAuth. STMAC: [BC:F5:AC:F6:30:50] [ 047 ACKs]

Listing 4.1: Syntax for Deauthentication using aireplay-ng

4.1.2 History of the Karma-attack

Karma was first implemented by Zovi et al. in 2004 [DZM05], and was an extensionof the, now deprecated, MadWifi driver2 for Linux. To achieve the goal of associatingwith any client, this driver had to be modified. As a result, every incoming frame hadto be checked, and altered if needed. The SSID of every beacon and PReq frame isoverwritten to match the SSID of the AP, which requires the SSID validation to bedisabled. This approach has been changed in the implementation from Robin Wood3,released in 2008. The attack has been relocated from the wireless driver to a user spaceprogram responsible for APs and authentication called hostapd4. Nevertheless, the basicsof the attack remain unchanged, though some details have been tweaked: In addition toa more granular control via CLI it is now possible to black- or whitelist SSIDs.

2http://madwifi-project.org/, as of March 1, 2015 – Official Homepage of the, now deprecated,MadWifi WLAN driver for Linux.

3http://digi.ninja/karma/, as of March 1, 2015 – Official Homepage of R. Wood’s Karma implemen-tation.

4http://w1.fi/hostapd/, as of March 1, 2015 – Official homepage of the hostapd application by JouniMalinen.

4.1 Karma: A Powerful Hacker Tool and Our Countermeasure 19

R. Wood improved the MadWifi implementation as well, and ported it to the OpenWRTOS for routers. It was published using the name Jasager5 (“yes-men”). Part of thisimplementation is an easy-to-use webinterface, which is shown in Figure 4.2. It shows adetailed list of connected clients, as well as the log file of Karma. The control buttonsreflect the available commands of the CLI version: two buttons to enable the wirelessinterface, and the Karma-attack, a minimal filter in either black- or whitelist mode,including buttons to manually add a SSID and to reset the list. Among the new features isa module system. Modules are user-written scripts which receive the MAC and IP addressand the requested SSID of clients connected to the Karma-hotspot. The functionalityof these modules is not restricted, and can range from access and traffic logging, over aport-scan via nmap to a full-fledged vulnerability analysis using Nessus6.

Figure 4.2: Web interface of the Jasager implementation, 2008.

5http://digi.ninja/jasager, as of March 1, 2015 – Official Homepage of R. Wood’s Jasager application6http://www.tenable.com/products/nessus-vulnerability-scanner, as of March 1, 2015 – Official

homepage of the Nessus Vulnerability Scanner.

20 4 Security Enhancing and Privacy Preserving Techniques

The implementation of Jasager has been picked up by the Hak57 group to create thePineapple, which has been described in Section 2.3.2. The latest improvement was shownat DEF CON 22 [IdV14], de Vielliers et al. started by analyzing the behavior of moderndevices regarding PReqs, showing that the previous attack is not always sufficient. Thisis due to modern devices tending to use broadcast PReqs, and reducing the amountof PReqs sent in general. They were able to mitigate the first problem, by collectingrequested SSIDs and sending those within a directed PResp. It is important to note thatin this thesis we only consider devices sending directed PReqs and devices that have anopen network stored in their PNL (see Chapter 3).

4.1.3 Our Detection ProgramWe build a program to detect the attack, that works as simple as the attack itself.Knowing that an attacker listens for directed PReqs of any device, our detector sendsmultiple directed PReqs using randomly generates SSIDs. As described in Section 2.1,SSIDs consist of up to 32 characters using 7-bit ASCII. Of its 128 characters only 94are printable. Keeping the space character in mind, this results in 93 · 9431 ≈ 9.91 · 1062

different combinations for SSIDs. Thus it is sufficient to send only a single PReq for arandom SSID, as the probability of receiving a beacon or PResp is ≈ 2−209. Receiving sucha response strongly implies an active attacker. The pseudocode of our implementation isshown in Algorithm 4.1.1.

Algorithm 4.1.1: Karma-Detector (Pseudocode)1 begin2 𝑠𝑠𝑖𝑑← getRandomSsidName()3 sendProbeRequest(𝑠𝑠𝑖𝑑)

/* Listen for incoming Beacons and Probe Responses */4 enableMonitorModeAndPacketCapture()5 if receivedPacket.type == “Beacon” or receivedPacket.type == “Probe Response”

then6 if receivedPacket.ssid == ssid then7 𝑟𝑒𝑐𝑒𝑖𝑣𝑒𝑑𝑃𝑎𝑐𝑘𝑒𝑡.𝑖𝑠𝑀𝑎𝑙𝑖𝑐𝑖𝑜𝑢𝑠𝐹𝑟𝑎𝑚𝑒← true

𝑟𝑒𝑐𝑒𝑖𝑣𝑒𝑑𝑃𝑎𝑐𝑘𝑒𝑡.𝑖𝑠𝐹𝑟𝑜𝑚𝐴𝑡𝑡𝑎𝑐𝑘𝑒𝑟 ← true

7https://hak5.org/, as of March 1, 2015 – Official Homepage of Hak5 LLC.

4.2 The WLAN-Standard vs. Privacy 21

4.2 The WLAN-Standard vs. Privacy

The following Section deals with the privacy issues of WLAN. Many devices sendprivate data without any encryption. This allows anyone in the vicinity to capture theseinformation.

4.2.1 Tracking, Metadata and Other Information for Free

As it was explained in Section 2.2, enabling monitor-mode on a wireless interface allows itto process all received packets, including those intended for another recipient. While mostdata frames are encrypted and thus unreadable, one can still count the quantity and sizeof sent packets as well as the sender and the recipient inside the network. One is also ableto receive control frames like “request-to-send”, “acknowledgment”, and managementframes belonging to the authentication and association process (see Figure 2.2). However,these information provide limited value to an eavesdropper, assuming that he cannotdecrypt the data frames. The most valuable information are included in beacons, PReqsand PResps. These packets can be used to create an overview of active wireless devicesin the vicinity. Later on, in Section 5.3, an Android application which implements thisprecise feature is presented.

When one regards the bigger picture, the problem becomes more apparent: Analyzingthe captured data of a single time and place provide a relatively limited value. However,these information can be linked between multiple locations, allowing eavesdroppers todraw conclusions on the identities of people. Recent research, as described in Section 1.2,shows that this is possible as long as there is a large amount of raw data for evaluation.

4.2.2 SSID-Mixer: Privacy Protection for Everyone

While our tool cannot prevent eavesdropper from collecting data, we can inject additional,fake data and thus falsify their captured data. This can be achieved by collecting a listMAC addresses of active devices, as well as a list of the recently requested SSIDs. TheSSID-Mixer combines these lists and injects PReqs for each combination. Our intention isthat an eavesdropper cannot distinguish between the “original” and our faked PReqs, thusthe collected data cannot be evaluated for meaningful results. The effect is demonstratedin Figure 4.3, showing an exemplary behavior of PReqs in Figure 4.3a. Figure 4.3b showsthe effect of SSID-Mixer, where PReqs are injected for all combinations of a subset ofboth devices and SSIDs, with PReqs for additional being added. Figure 4.3b shows amode of operation that injects PReqs for additional devices that are not existing at thelocation. This mode is not implemented as part of this thesis, and is left for future work.

This first implementation is a rather naive approach, and focuses on the group of mostrecently active devices. The algorithm joins their PReq to create a combined PNL ofall devices within the group. The created “connections” are subsequently created byinjecting PReqs. During the last step, the MAC address of the wireless interface has tobe changed regularly to reflect the device that is currently imitated. The PReqs are sentone at a time, as a single PReq cannot contain more than one SSID. The pseudocode of

22 4 Security Enhancing and Privacy Preserving Techniques

MAC-1

MAC-2

MAC-3

MAC-4

MAC-5

SSID-1

SSID-2

SSID-3

SSID-4

SSID-5

(a) Without SSID-Mixer.

MAC-1

MAC-2

MAC-3

MAC-4

MAC-5

SSID-1

SSID-0

SSID-2

SSID-3

SSID-4

SSID-5

SSID-6

(b) With SSID-Mixer, addingonly SSIDs.

MAC-1

MAC-0

MAC-2

MAC-3

MAC-4

MAC-5

MAC-6

SSID-1

SSID-0

SSID-2

SSID-3

SSID-4

SSID-5

SSID-6

(c) With SSID-Mixer, addingboth devices, and SSIDs.

Figure 4.3: Comparing captured Probe Requests with SSID-Mixer enabled and disabled.Red lines indicate PReqs injected from SSID-Mixer. Red MAC addresses,and SSIDs indicate virtual entities, added from SSID-Mixer as well.

our implementation is shown in Algorithm 4.2.1.

Algorithm 4.2.1: SSID-Mixer (Pseudocode)Data: ssids[0 . . . 𝑛], devices[0 . . . 𝑚]

1 begin2 ssids ← getRecentlyActiveSsid(length[ssids])3 devices ← getRecentlyActiveDevices(length[devices])4 for 𝑖← 0 to length[devices] do5 changeInterfaceMacAddress(devices[𝑖].mac)6 for 𝑗 ← 0 to length[ssids] do7 sendProbeRequest(ssid[𝑗])

In a revised implementation, we have devised two alternative criteria to select devicesand SSIDs. Contrary to the first mode, which selects devices based on the time of theirlast activity, the new modes select devices based on the size of their PNL, and SSIDsbased on the number of clients requesting them. However, the last activity is still afactor, as we do not want to inject PReqs for devices that are already gone.

For the algorithm, we mix either (i.) the least active devices, i. e., those with a PNLof three (ii.) or less entries with the most popular recently requested networks, or theother way around. We assume that devices with a small PNL have a relatively largeramount of unique SSIDs that they request.One can pinpoint them to a location by usingan online Database (DB) on WLANs. By adding PReqs for popular networks for thesedevices, we intend to mask this relationship. The inverse of this mode, combining devicewith a larger PNL with the least requested networks, has a similar intention. If a device

4.2 The WLAN-Standard vs. Privacy 23

requests many different SSIDs, it is also possible to connect them to different locations.By adding unrelated networks, one can falsify an evaluation of these devices. As a sideeffect, the relationships of SSIDs injected in this mode, are also falsified.

The active mode should be chosen by the average length of the PNL, and the averageduration of stay of active, nearby devices.

5 Testbed Implementation

This chapter begins with an introduction of the utilized devices, a smartphone and aUSB WLAN adapter, and why these specific devices were chosen. A custom OS has beeninstalled on the smartphone, along with a modified kernel and other modifications fora working communication between both devices. It is crucial that the WLAN adapteris capable of using the monitor-mode and performing packet-injection, thus two small“demo programs” were written to verify this functionality. In the second half of thissection, the Android application “WifiAnalyzer” is presented. This application accessesthe connected WLAN adapter and processes the captured frames to show active WLANstations in the vicinity.

5.1 Devices

One of the main goals of this thesis, is to implement the defensive tools shown inChapter 4 on a smartphone. While this increases the required effort for development,it provides a better platform for demonstration, as smartphones can be consideredubiquitous. Under these conditions, the Android OS is an obvious choice between themajor three smartphone OSs. Contrary to Apple’s iOS and Microsoft’s Windows Phone,only Google’s Android allows developers full control over the device. This is necessaryto use the WLAN adapter via USB. In practice, only a few Android smartphones allowthe use of external USB devices, fortunately the Nexus 5, being the official device fordevelopers, is amongst them. In September 2014, when the device was purchased, ithad a retail price of 315e. Therefore it offers an outstanding price/performance ratio,as other smartphones with a comparable processing power had a retail price of roughly500e1.

For the WLAN adapter, we chose the TP-Link TL-WN722N for three reasons. First,it is supported by every major OS, thus we expect a reduced effort to install it on anAndroid smartphone. It is also capable to process every received packet, independent ofits intended recipient (monitor-mode). And lastly, it is capable to send arbitrary packets(packet-injection). Other devices, with similar capabilities, are available, however thechipset is produced by Atheros, a long-established company in the industry. Additionallyit has a very low retail price of 10e.

1The Samsung Galaxy S5 had a retail price of about 480e, the HTC One M8 was available for roughly520ehttps://geizhals.de/?phist=1075683, as of March 1, 2015 – Price history for the Sam-sung Galaxy S5.https://geizhals.de/?phist=1090939, as of March 1, 2015 – Price history of the HTC One M8.

26 5 Testbed Implementation

The devices can be connected by using a Universal Serial Bus (USB) On-The-Go (OTG)cable, which is available for 5e. Both devices, the smartphone and the WLAN adapter,are shown in Figure 5.1.

(a) Nexus 5, codename hammerhead1 (b) TP-Link TL-WN722N2

Figure 5.1: The devices used for this thesis.

5.2 Technical PrerequisitesThis Section describes the different steps necessary to use the TP-Link adapter on theNexus 5 smartphone. Firstly, the developing and testing environment, which is used forapplication development and to monitor the wireless traffic are described. Secondly, thenecessary steps to compile the OS, how to modify the kernel, and how it can be installedon the smartphone are covered. To verify that the device works as intended, two smalldemo programs have been created.

5.2.1 Building and Testing Environment

We have chosen to use a Linux based OS for our environments as it offers great versatility,and is comparetively easy to use for programming. Especially if the target OS is alsobased on Linux. We have decided to use Linux Mint (version 17) for development, andKali Linux (version 1.0.9) for testing purposes. Both systems are deployed using VMwareWorkstation (version 11.1.0) as Virtual Machines (VMs) offer great portability betweensystems, and are mostly independent from the host OS.

1https://play.google.com/store/devices/details?id=nexus_5_black_16gb, as of March 1, 2015 –Image source for Figure 5.1a.

2http://www.tp-link.com/resources/images/products/large/TL-WN722N-01.jpg, as of March 1,2015 – Image source for Figure 5.1b.

5.2 Technical Prerequisites 27

For development we require different software packages. One of the most importantpackages is the Android Developer Tools (ADT) bundle, consisting of the AndroidSoftware Development Kit (SDK) (version 24.0.2) and Eclipse (version 4.2.1 “Juno”).Oracles Java Development Kit (JDK) has been installed as well (version 1.8.0_31).Although ADT has been superseded by the Android Studio Integrated DevelopmentEnvironment (IDE), which was released in December 2014, we have decided to staywith Eclipse as we do not gain any benefit by switching. Furthermore, the programsAndroid Debug Bridge (adb) and fastboot are necessary. Adb is used to interact withthe device while the OS is fully booted, while fastboot controls the bootloader. A listof the most important commands can be found in the Appendix A.2. Both tools areincluded as part of the Android SDK. For increased ease of use one can add the toolsto the PATH-variable, allowing them to be accessed in any folder by appending exportPATH=$PATH: /android-sdk/platform-tools to ~/.bashrc. The Native DevelopmentKit (NDK) (version r10d) is our final software requirement. It is necessary to compilethe binaries for the demo programs, as it includes the C compiler for ARM platforms(“arm-linux-androideabi-gcc-4.9”). A small script for this task is shown in Listing A.23.As the SDK, the source code and additional files created during compilation requiremuch disk space, we recommend to have at least 75 GB available.

As our testing environment uses Kali Linux, it comes with all relevant software packagespreinstalled, this includes the tool ifconfig, the “Wireless tools” software-suite as well asa terminal emulator. However the environment serves only a single purpose: monitoringWLAN traffic to verify the applications work as intended. For this only one applicationis required: Wireshark (version 1.10.2, described in Section 2.3.1). A second TP-LinkTL-WN722N is used on this machine.

5.2.2 Compiling Android OS and Kernel Modifications

Instead of using an unmodified version of Android, sometimes referred to as “stock” or“vanilla”, a community-maintained version (“Custom-ROM”4) called CyanogenMod (CM)5

has been chosen. CM is amongst the most popular Custom-ROMs, as it is available formany Android phones.

This version offers various advantages. It has an online documentation (“wiki”), thatoffers in-depth tutorials how the system can be compiled and installed. Once the OS isinstalled, it is already configured to support application that need superuser (root) access.In addition, a terminal emulator for shell access is installed. Both the root-access andthe terminal emulator are required to interact with the wireless adapter. Granted, theadditional software and the root-access can be configured on other systems with minimaleffort. However the depth of the documentation is unmatched on other Custom-ROMs.

The online documentation6 describes the necessary steps to compile CM from its4The abbreviation ROM originates from embedded electronic devices, where the OS is stored on Read

Only Memory (ROM).5http://www.cyanogenmod.org, as of March 1, 2015 – Official homepage of the CyanogenMod project.6http://wiki.cyanogenmod.org/w/Build_for_hammerhead, as of March 1, 2015 – “How To Build

CyanogenMod Android for Google Nexus 5” in the CM wiki.

28 5 Testbed Implementation

sources:

1. Installing adb, fastboot and some software packes required for compilation on thedevelopment machine.

2. Unlocking the devices bootloader (fastboot oem unlock).

3. Initializing the a local copy of the source code’s git repository using the repocommand. If git has not been used before, the configuration file ~/.gitconfig hasto be created (see Listing 5.1).

4. Downloading the source code from the repository. This step may take a coupleof hours, depending on the available internet connection. Please note that weare using CM version 11 which is built upon Android 4.4 (“Kitkat”). AlthoughAndroid 5 (“Lollipop”) is already available, the corresponding version of CM is stillin development and not yet stable.

5. During the next step some prebuilt applications are downloaded and proprietarybinary files are extracted from the unmodified device.

6. In the final step the system is compiled. This is very resource intensive and thecomputer may take a few hours to complete this process. We recommend to enablethe caching option to speed up subsequent builds. The commands for a buildingthe complete OS and building only the kernel are shown in Listing 5.2. Keep inmind that a complete build is required to rebuild the kernel.

1 [user]2 email = Thomas.Kropeit@hgi.rub.de3 name = Thomas4 [color]5 ui = auto

Listing 5.1: Example content for the git configuration file (~/.gitconfig).

1 Building the complete system:2 $ cd ~/android/system/3 $ source build/envsetup.sh4 $ brunch hammerhead56 Building the kernel only:7 $ cd ~/android/system/8 $ source build/envsetup.sh9 $ breakfast hammerhead

10 $ mka bootimage

Listing 5.2: Commands to build the complete CM OS and only its kernel.

As the sources are unmodified until this point we expect the compilation to completewithout errors. However, we still need to modify the kernel to add support for theTP-Link adapter. The tool menuconfig is used to change the kernel, as it shows thestructure and a brief description of the different options (see Figure 5.2). It can beaccessed as described in Listing 5.3. The additionally activated options are shown in

5.2 Technical Prerequisites 29

Listing 5.4. Every option is enabled as a kernel module (<M>), this means it has to beloaded on-demand using modprobe $extension.

Figure 5.2: The menuconfig tool to configure the Android kernel.

1 Create a configuration backup:2 $ cd ~/android/system/kernel/lge/hammerhead/arch/arm/configs/3 $ cp cyanogenmod_hammerhead_defconfig cyanogenmod_hammerhead_defconfig_backup45 Start the configuration tool:6 $ cd ~/android/system/kernel/lge/hammerhead7 $ ./make_defconfig.sh cyanogenmod_hammerhead_defconfig

Listing 5.3: Accessing the tool menuconfig to modify the kernel

1 Networking Support → Wireless → Generic IEEE 802.11 Networking Networking Stack (mac80211)23 Device Drivers → Network Device Support → Wireless LAN → Atheros Wireless Cards

Listing 5.4: Additional kernel options activated in menuconfig

At this point the kernel can be recompiled using the commands described in Listing 5.2.On the development VM, which has already compiled and cached CM, this step takesless than 20 minutes. The system images are combined into a zip-file which is located in~/android/system/out/target/product/hammerhead/.

30 5 Testbed Implementation

5.2.3 Device Initialization and OS Installation

Now the device is almost ready to be used. To continue with the installation we haveto copy the zip-file containing the just created version of CM onto the device. If, forany reason, the devices bootloader is not yet unlocked, this has to be done before thenew OS is installed, as it resets the internal storage. This can be achieved by issuing thecommand fastboot oem unlock while the device is in fastboot-mode (see Figure 5.3a).Additionally, a “custom recovery image” has to be installed. This allows us to create andrestore backups of the currently installed OS, as well as installing a new one like CM.The recovery image from Team Win Recovery Project (TWRP)7 has been chosen, as itsinterface is optimized for touch input (see Figure 5.3b).

(a) Nexus 5 in fastboot-mode. (b) Nexus 5 in recovery-mode.

Figure 5.3: The Nexus 5 in fastboot- and recovery-mode.

To copy the zip-file containing CM the device has to be fully started and connected to acomputer using a USB cable. The OS can be installed (“flashed”) by choosing the install-option in TWRP and selecting the file. However, to guarantee a clean install, we advise towipe all existing partitions expect the internal storage (select Wipe → Advanced Wipe inTWRP). If the kernel has been compiled independently from the OS, that is if after thekernel modifications only the kernel has been recompiled, it has to be installed additionally.This can be achieved by booting the device into fastboot-mode, and issuing the command

7http://teamw.in/project/twrp2/205, as of March 1, 2015 – Official project website of TWRP.

5.2 Technical Prerequisites 31

fastboot flash boot boot.img. The kernal image (boot.img) is located in the samefolder as the zip-file – ~/android/system/out/target/product/hammerhead/.

At this point only the firmware for the TP-Link WLAN-adapter, ath9k_htc8, ismissing. We identified the required driver by running dmesg on our development VMwhile connecting the adapter. The downloaded file needs to be copied onto the device intothe folder /system/vendor/firmware/. This can be achieved by executing adb pushhtc_9271.fw /system/vendor/firmware/.

5.2.4 Demo Programs

Now the smartphone can interact with the additional Network Interface Controller (NIC),however it has to be verified that the WLAN adapter is working as intended. To enablethe adapter, one has to issue two commands: modprobe ath9k_htc to activate thekernel module and ifconfig wlan1 up to activate the interface. These commands areautomatically executed in the following implementations.

To verify the functionality, one can use the iwlist $nic scan command to scan forWiFi-Networks in range (see Listing A.18). The program essentials creates a PReq andevaluates the responses. Without any additional parameters a broadcast PReq is sent,specifying the SSID by adding ssid $ssid creates a directed PReq.

To verify that both monitor mode and packet injection are working, we wrote two smallprograms using the pcap-library. The first program, pcapScanner-demo.c, implementsa rudimentary scanner for IEEE 802.11 packets. Excerpts of the code are shown inListing A.1, a complete version is on the disc supplied with this thesis. It consists ofthree steps:

1. Initializing the interface using modprobe, ifconfig and iwconfig.

2. Initializing pcap and create a handle to access the incoming data.

3. Starting pcap and defining a function to process the captured packets.

The second program, pcapInjection-demo.c, implements rudimentary injection ca-pabilities. It is based on a code snippet provided by Jan-Felix Posielek, student workerat the Chair of Embedded Security. The complete code is also available on the supplieddisc.

The capability to inject arbitrary packets is used in both programs, Karma-Detectorand SSID-Mixer, however both only need to inject PReqs. Unfortunately, there was aproblem with our implementation. While we were able to generate proper PReqs, theydo not contain the correct Basic Service Set Identification (BSSID). This results in thepackets being disregarded from routers or the Pineapple. To resolve this issue, we wouldlikely have to modify the wireless driver itself. This is a very complex task, which wehave deemed out of scope for this thesis. As a fall-back solution we are able to usethe command iwlist $nic scan ssid $ssid, however this solution results in a lower

8http://wireless.kernel.org/en/users/Drivers/ath9k_htc, as of March 1, 2015 – Documentationon the Linux wireless driver ath9k_htc.

32 5 Testbed Implementation

performance. The custom implementation sends up to 20 packets per second, whereasiwlist pauses for roughly 1.100 ms between each packet, and sends 3 PReqs per command.As the applications is mostly a proof-of-concept, this speed is sufficient.

The first versions of Karma-Detector, and SSID-Mixer were in the form of a stand-alone binary. However, due to the good progress of the Android Application from HenrikKroll in [Hen15], they were soon integrated. The next section presents our joint effort,starting with a general introduction of the application.

5.3 Android Application “WifiAnalyzer”

This Section describes the Android application, which was jointly created with HenrikKroll (see [Hen15] for his thesis). We will start with a general introduction and continuewith a detailed description of the defensive extensions.

5.3.1 General Presentation

The purpose of the application is to create an overview of nearby, active wireless devicesand display details of their WLAN communication. The gathered information can beused to create statistics on available stations, for example the number of clients sendingdirected PReqs versus the amount of clients sending broadcast PReqs, the average PNLsize between clients, and potential victims to the Karma attack. Our own evaluation isshown in Chapter 6.

Once the application is started, the wireless adapter has to be initialized as describedin Listing A.2. While it is possible to execute these commands directly in Java, theimplementation turned out to be error-prone. A simple solution was to execute thesame commands using a C-binary (Listing A.2), which is working flawlessly. The nextstep is to initialize the MAC address Lookup table (LUT). MAC addresses consist oftwo parts: the first 3 Bytes (prefix) are used to identify the NIC’s manufacturer, thelast 3 Bytes (suffix) are a unique value to identify the NIC. As there are only a fewOriginal Equipment Manufacturers (OEMs) for NICs, and many companies using themin their own equipment, the MAC prefix contains the latter name. For example, theprefix 00:00:F3 is owned by “Gandalf Data Limited”. The LUT contains the associatedcompany name for each assigned MAC prefix. For a fast access, the downloaded file9 isconverted into a hash table.

The applications main interface shows a graph on which active devices are placeddepending on the packets RSSI value (Figure 5.4a). The graph has a range of 0 dBmto −100 dBm, a low RSSI value indicates that the device is further away. The datais supplied by the C-binary pcapSniffer and a single dataset includes the followinginformation: source (MAC) address, destination (MAC) address, BSSID, frame type,SSID, channel Frequency, signal strength (RSSI) and the packet length. We differentiatebetween the following frame types, identified by the Type/Subtype flag: Probe Request,

9A daily updated copy is published by the IEEE: http://standards-oui.ieee.org/oui.txt

5.3 Android Application “WifiAnalyzer” 33

Probe Reponse, beacon, Deauthentication and data. Other frame types, for exampleAcknowledgment and Ready to Send, are disregarded.

(a) The scanning interface of WifiAnalyzer.

i. AP icon9. ii. Android icon10.

iii. Apple icon11. iv. Attacker icon12.(b) The icons used to distinguish between wireless

stations.

Figure 5.4: The main interface of the application WifiAnalyzer and the used icons.

We are using 4 different icons for devices, as seen in Figure 5.4b: a generic icon forAPs, an Android icon for both Android and other (unidentified) devices, the Apple Inc.logo for Apple devices, and a devil icon for identified attackers.

A SQLite DB is used to store our captured data. SQLite is the database managementsystem of choice for small databases or for resource constricted devices. It can beaccessed using common libraries, and contrary to other systems, it does not net aseparate management process, yet one can use regular Structured Query Language (SQL)commands.

Every received packet is stored in a SQLite DB, within the table frames. An additionaldataset, one for each source (MAC) address, is created in the table sources. The structureof both tables is shown in Figure 5.5. It is assumed that only APs send beacon frames,and thus the boolean flag “is_ap” is set to true once a beacon frame has been capturedfrom this address. The flag “is_evil” behaves similarly – it is set to true if an attack (see

9http://simpleicon.com/wifi-signal-2.html, as of March 1, 2015 – Image source for the AP icon.10This icon is available in the Android SDK.11https://www.iconfinder.com/icons/115412/apple_icon#size=128, as of March 1, 2015 – Image

source for the Apple icon.12http://wallpaperwidehd.blogspot.de/2014/04/robot-devil-futurama-wallpaper.html, as of

March 1, 2015 – Image source for attacker icon.

34 5 Testbed Implementation

Section 5.3.2) originating from this MAC address is detected.

frames

- id (int)- source address (varchar(17))- destination address (varchar(17))- bssid (varchar(17))- ssid (varchar(40))- type (varchar(255))- rssi (int)- channel freq (int)- timestamp (long)- sniff description (varchar(100))- packet length (int)

(a) Structure of the DB table frames.

sources

- id (int)- src (varchar(17))- nickname (varchar(255))- manufacturer (varchar(255))- packets sent (int)- is ap (int)- is evil (int)

(b) Structure of the DB table sources.

Figure 5.5: The database structure of the application WifiAnalyzer.

Selecting a station within the main interface opens a detailed view of this station(Figure 5.6). The first page, seen in Figure 5.6a, shows generic information on the device,including the MAC address and its vendor, the time of the last known activity, and apie chart showing the distribution of the type of sent messages. The second page, seenin Figure 5.6b, shows a list of requested SSIDs for clients, and a list of communicationpartners. The latter is broken down into 3 different views: messages sent to other stations,messages received from other stations, and a combined list of addresses. The last page,seen in Figure 5.6c, plots the RSSI values and allows to the user to check if the distanceto the device has been increased or decreased.

Another feature of the application is the database viewer, accessible by the button “Net-work Overview”. The view filters the received packets using predefined SQL statements,which are listed in Appendix A.4. For example, list of stations, including a count ofsent packets grouped by type (Listing A.4), and a list of available or requested networks,respectively identified by beacons and PResps or by PReqs (Listings A.5 and A.6).

5.3.2 Defensive Extensions

The application has been enhanced by three additions: the Karma-Detector, the SSID-Mixer, and a DeAuth feature. The Karma-Detector and the SSID-Mixer can be activatedwithin the “3-dot menu”. A DeAuth can be send from the station detail window.

The first addition, the Karma-Detector has been implemented as a singleton-class.Once it is accessed for the first time, a list of random SSIDs is generated and injected.The SSIDs are subsequently requested by calling iwlist. Meanwhile, the SSID of allreceived packets is checked against the created list. If a match is detected, the sendingparty is marked as an attacker (“is_evil” ← true), the stations icon is replaced by theattacker symbol (Figure 5.4b), and a “toast” message is displayed on the bottom of thescreen (Figure 5.7).

5.3 Android Application “WifiAnalyzer” 35

(a) A breakdown on receivedpackets and general informa-tion.

(b) Requested SSIDs and com-munication partner of oneWLAN station.

(c) The history of RSSI values.

Figure 5.6: The GUI in the application WifiAnalyzer showing detailed information on aselected station.

The second feature, the SSID-Mixer has also been implemented using a singleton-class.On initialization it creates a list of recently active devices (MAC addresses) and networks(SSIDs) using the SQL queries from Listings A.8 and A.9. All three modes shown inSection 4.2.2 are implemented. The different combinations are injected by using ifconfigand ip to change the MAC address (see Listing A.3) and iwlist to request the network.

Our third addition is the DeAuth feature. It relies on the program aireplay-ng14. Itssyntax was described earlier in Listing 4.1. Clients can be deauthenticated by selecting theDeAuth button from the station detail view (Figure 5.6b). If the selected station is an AP,all clients will be deauthenticated. Otherwise, if the station is a client, the applicationtries to identify the clients AP by adding the clause WHERE sources.is_ap == 1 toListing A.11. In case we receive multiple results, DeAuth packets for all combinationsare injected. In order to DeAuth all clients from all recently active APs, the command“DeAuth all” can be accessed from the “3-dot menu”. The active APs are supplied byListing A.10. A mode that continuously deauthenticates all APs is not implemented, andleft for future work.

14http://www.aircrack-ng.org/doku.php?id=aireplay-ng, as of March 1, 2015 – Official documenta-tion of aireplay-ng

36 5 Testbed Implementation

Figure 5.7: The main interface of WifiAnalyzer when a Karma-attack is detected. Thesymbol of the attacker has been changed, and a “toast” message is shown atthe bottom of the screen.

5.3.3 Testing the Application

Testing the application is a crucial part during the development phase. Every program,even those with a short code, needs to have its functionality evaluated. A commonmistake is an incorrect variable initialization, causing the program to fail, even thoughthe main functions are working correctly.

The core of the presented application is the packet scanner. If this program returnsincorrect packets, or even fails to return some, the WifiAnalyzer is directly affected. Toensure a correctly working application, the output has been regularly compared to theresults of Wireshark in the testing environment. It has been noticed that some capturedpackets contain an incorrect SSID, more precisely a SSID that contains additional non-printable characters. This has been solved by using the function isprint() of the libraryctype.h to check for non-printable characters.

As has been mentioned before, the custom implementation for packet injection did notwork as expected. We believe, this has been caused by the wireless driver overwritingcertain values. For PReqs, the values for destination MAC address and BSSID need to

5.4 Monitored Hotspot via Command-line Interface 37

be set to FF:FF:FF:FF:FF:FF, the source MAC address is set to the sending stationsMAC address. However, even though the BSSID is manually set to FF:FF:FF:FF:FF:FFin the forged packet, the BSSID of the injected packet has been set to the stations MACaddress. The resulting PReq is incorrectly formatted, and thus ignored by APs.

During the implementation of the Android application, some problems were encounteredas well. Android applications require a “context” for many task, for example changingthe active interface, showing a dialog window, or accessing the SQLite DB. If one isunfamiliar with this procedure, it can be time consuming to achieve the desired task,as the applications crashes if the context is set incorrectly. Using the tool logcat isimportant during this development phase, as it offers an easy way to identify the incorrectline of code by providing a core dump.

5.4 Monitored Hotspot via Command-line Interface

Using hostapd an open network can be created via command-line. This hotspot does notoffer Karma-capabilities, i. e., sending beacons and PResps to every network requestedvia PReqs. However, a popular name can be chosen, for example, by manually checkingthe DB, and wait for clients to connect. The resulting traffic can be captured withlittle effort, for example, by using the Android application “Shark for Root”15, whichcreates a pcap-file that can be analyzed using Wireshark. The custom hotspot relieson three programs: hostapd for the AP, dnsmasq for the Dynamic Host ConfigurationProtocol (DHCP) server, and iptables for packet routing. The configuration file for hostapd(hostapd.conf, Listing A.16) has to be copied to /etc/hostapd/ and that of dnsmasq(dnsmasq.conf, Listing A.17) to an arbitrary location, for example /sdcard/hotspot/.Furthermore, iptables has to be configured to route packets between the wlan0, theinternal WLAN-interface, and wlan1, the TP-Link adapter used to create the hotspot, asdescribed in Listing 5.5. This allows the hotspot clients to use our own WLAN connectionto access the Internet. After these prerequisites are resolved, the hotspot can be startedby issuing the commands from Listing 5.6.

1 # enable IP-forwarding2 echo 1 > /proc/sys/net/ipv4/ip_forward34 # remove a default rule that drops traffic5 iptables -D natctrl_FORWARD 167 # enable packet forwarding from wlan1 to wlan0.8 # the hotspots DHCP-server is configured to 192.168.150.0/24.9 iptables -A FORWARD -o wlan0 -i wlan1 -s 192.168.150.0/24 -m conntrack --ctstate NEW -j ACCEPT

10 iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT11 iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE

Listing 5.5: Enabling IP-forwarding and configuring the firewall.

15https://play.google.com/store/apps/details?id=lv.n3o.shark, as of March 1, 2015 – “Shark forRoot” in the Google Play Appstore

38 5 Testbed Implementation

1 # set the interfaces address to 192.168.150.1, part of the subnet defined in dnsmasq.conf2 ifconfig wlan1 192.168.150.134 # start dnsmasq using the specified configuration file to5 # --no-resolv, --no-poll: resolve only servers from the configuration file6 # --no-daemon: run in debug mode, showing all actions directly within the shell7 dnsmasq --no-resolv --no-poll --no-daemon --conf-file=/sdcard/hotspot/dnsmasq.conf89 # execute the next command from a second terminal window/shell!

1011 # start hostapd using the specified configuration file12 hostapd /etc/hostapd/hostapd.conf

Listing 5.6: Starting the hotspot.

Once the hotspot is started, one can start to capture the traffic using “Shark for Root”.Its GUI is very simple, however the default parameter for packet capture needs to bechanged to -vv -s 0 -i wlan1 (-vv for verbose output, -s 0 sets the packet size to65535 bytes, -i wlan1 sets the capture interface to wlan1 ). The generated pcap-file issaved in /sdcard/. An example log of hostapd and dnsmasq is shown in Listings A.19and A.20.

6 Evaluation & Results

We have deployed our testing setup, consisting of the Nexus 5, the TP-Link TL-WN722N,and the WiFiAnalyser application, in different public locations and captured the wirelesstraffic. In this chapter we will present our evaluation of these results.

6.1 Current State

We have captured packets in 3 different locations: the main station of Bochum (main-station), and twice at the main cafeteria of Ruhr-University Bochum (mensa-1, mensa-2 ).The datasets mensa-1 and mensa-2 also include the trip by foot from building ID to thecafeteria and back.

Our main results are shown in Table 6.1. We expect the results from the train stationto be similar, but slightly different to the measurements from the university. We makethis assumption as the cafeteria offers multiple APs for “eduroam”, the university-wideavailable WLAN, while the main station offers only a few WLANs. As a result, weexpect more clients to be connected to a WLAN at the university, and thus send fewerPReqs. However, our collected data shows a different result. The absolute number ofbroadcast PReqs is similar across all datasets, while the absolute number of directedPReqs is significantly higher in mensa-1 and mensa-2. We believe this is connected tothe average duration of stay of clients, which is significantly higher as well. Client devicessend their PReqs in bulk and in regular intervals. This interval is longer than 200 s onseveral modern devices [DW14], giving a plausible explanation for the different amountof directed PReqs measured.

Using different SQL queries, we were able to further analyze the data (Appendix A.4.1).The PNL length of each station has been calculated using Listing A.14 and the durationof stay using Listing A.15. The result of the former is shown in Figure 6.1. We noticedthat a large amount of clients have a PNL of only one or two SSIDs. We believe thatmost of these devices only probe for their last connected network. A behavior that wasalso noticed in [DW14].

Given that only the sent packets of each station are analyzed, and that no methodof communication with the station itself is available, the devices cannot be accuratelyidentified. The only available characteristic is the NIC vendor. This is sufficiently accurate,as all of the most popular vendors in our datasets produce smartphones. However, ourresults show that devices from the same vendor behave differently regarding PReqs, i. e.,some devices send directed PReqs while others send only broadcast PReqs (Figure 6.2).

1some devices sent neither beacons, PResp nor PReq2Stations with a PNL greater than 3.

40 6 Evaluation & Results

Table 6.1: This tables gives an overview of the measurements performed at Bochumsmain station and Ruhr-Universities cafeteria. It shows the number of stationsat each location and distinguishes between APs and clients. The capturedPReqs are divided into broadcast and directed PReqs and the number ofclients sending directed PReqs is calculated.

Dataset main-station mensa-1 mensa-2Date 02/23/15 02/19/15 02/25/15

Time/duration 07:32 – 08:20 12:24 – 13:26 12:27 – 13:12

Frequency [GHz] 2.437 2.437 2.437

# available WLANs(unique SSIDs)

11 25 19

# stations1 976 1.455 1.157

# stations sending beaconsand PResps (i. e., APs)

14 77 57

# stations sending PReqs(i. e., clients)

935 1320 1038

# stations sending data 53 87 85

# packets 42.512 93.088 65.016

# broadcast PReqs 10.816 12.053 9.361

# directed PReqs 7.108 26.708 23.291

# total PReqs 17.924 38.761 32.652

# stations sending directedPReqs

222 (23.7%) 794 (60.2%) 647 (62.3%)

Avg. PNL length 3.33 1.43 1.59

# requested SSIDs 585 396 409

# requested SSIDs by morethan one station

48 27 33

Avg. duration of stay(clients only) [s]

137 495 365

# potential Karmavictims2

46 (4.92%) 30 (2.27%) 31 (2.99%)

# detected Karma attacks 0 0 0

6.1 Current State 41

0 5 10 15

100

101

102

103

Length of the PNL

Number

ofdevices

main-stationmensa-1mensa-2

Figure 6.1: The length of the PNL across all datasets.

This implies that the implementation has been changed, most likely through a softwareupdate. A similar conclusion was drawn in [DW14].

Apple

Samsung

HTC

Sony LG

0%

10%

20%

30%

main-stationmensa-1mensa-2

(a) Top 5 vendors over all datasets.

Apple

Samsung

HTC

Sony LG

20%

40%

60%

80%

main-stationmensa-1mensa-2

(b) Top 5 vendors over all datasets, comparingthe amount of devices sending directed PReqsvs. the amount of total PReq per vendor.

Figure 6.2: The top 5 vendors, comparing all PReqs and only directed PReqs.

We also noticed that some SSIDs, which likely belong to a personal network due totheir name, are requested by a high number of devices (with unique MAC addresses).However theses device posses an identical PNL, which leads us to believe that thesedevices implemented a MAC randomization feature. By using this, the device regularlychanges the MAC address of the WLAN interface while sending PReqs. The result issimilar to our SSID-Mixer, although limited to a single device. On Android devices it is

42 6 Evaluation & Results

available with the application “PryFi”3, and on some Apple devices with iOS 8, althoughonly with certain restrictions4.

To identify possible victims of a Karma attack, we tried to compare our results tothe online WLAN DB WiGLE.net5. This DB has over 179 million SSIDs stored, withentries all over the world. The website offers an online search function6. However, acomparison with our own datasets turned out to be difficult. A search for several SSIDhas shown that either no match, or multiple matches across the global. In the very rarecase of a result within Germany, the entry could be as old as a decade. Considering theseresults, and as the website does not offer an option to evaluate multiple SSIDs at once,we have deemed it unfit for our task. Unfortunately there are no alternative DBs with acomparable amount of data.

As an alternative, we consider every device with a PNL with more than 3 entries,excluding the SSID “Broadcast” from broadcast PReqs, a potential victim to Karma-attacks. While this mostly an approximate value, we assume that a large PNL implies ahigher probability of the device being vulnerable to Karma. The estimated number ofaffected clients under this condition is between three and five percent. A practical teston how many of these devices would actually connect to a Karma hotspot would be veryinteresting. However, we chose not to perform this test to avoid legal implications.

6.2 Countermeasure PerformanceWhile it is important to know how much information can be intercepted using WLANeavesdropping, we also wanted to know how our defensive tools performed.

The Karma detector implementation requires only 2 packets, one PReq to be sent,and one PResp or beacon to be received. Thus the detection is almost instantaneous. Inour lab, we receive a positive identification within 4 seconds.

As is has been mentioned earlier, in Section 5.3.2, the performance of our SSID-Mixeris rather mediocre due to iwlist. However, it is still sufficient in less crowded places. Wehave analyzed the performance using Wireshark, and are able to send one PReq every1.100 ms on average. Due to the implementation of iwlist, a fixed amount of 3 PReqs issend on each program call.

3https://play.google.com/store/apps/details?id=eu.chainfire.pryfi, as of March 1, 2015 –PryFi in the Google Play Appstore

4http://blog.airtightnetworks.com/ios8-mac-randomization-analyzed/,http://blog.airtightnetworks.com/ios8-mac-randomgate/, as of March 1, 2015 – Blog articleson the MAC randomization feature of iOS 8.

5https://wigle.net/, as of March 1, 2015 – Official Hompage of WiGLE: Wireless Network Mapping6https://wigle.net/search/, as of March 1, 2015 – Network Search of WiGLE

7 Conclusion

In this chapter, the results produced in this thesis are summarized and their impact onWLANs and their users is concluded. The chapters end with ideas to further improvethe applications, and suggestions for future work in this area.

7.1 Summary

In this thesis, we provided an overview of the basics of IEEE 802.11, also known asWLAN. We have introduced some of the associated problems, while keeping a focus onprivacy issues and leaks of private information. The amendment 802.11w intends to fixsome of these issues by applying Message Integrity Codes (MICs) to management frames.However, the project remains in draft-status since 2009 and appears to be abandoned.

The Karma attack was first presented in 2004 and is still highly efficient againstmobile devices. Fortunately, a long term improvement is in sight, as mobile devicesgradually receive software updates. These updates change the device’s behavior to usebroadcast PReqs, which make the device partially resistant against Karma. Besides, thedetection of a Karma attacker is relatively easy, as we have shown with our Karmadetector. The detector can be installed on compatible smartphones with medium effortand without losing portability.

Eavesdropping on wireless transmissions remains a problem to be solved. Monitoringdevices can be installed in public places and used for device-tracking. The results may beused for marketing purposes, or other research. Political motives are also imaginable. Ourcountermeasure, the SSID-Mixer, works reasonably well to tamper with the measurementresults. For a satisfactory result, the SSID-Mixer has to be run in regular intervals andideally from multiple devices, i. e., multiple vantage points.

A “MAC randomization” feature was already implemented on some mobile devices. Itregularly changes the devices MAC address to prevent links between requested SSIDs,through PReqs, and the device itself, identified by its MAC address. We believe that thisfeature is an interesting approach that needs to be adopted from more manufacturers.

As a bottom line, we recommend to disable WLAN interface on all devices if it is notin use. A variety of automation applications that can perform this task, amongst others,is available for Android smartphones and tablets. Furthermore, we advise users to keeptheir devices PNL as small as possible. Especially open networks provide a risk to theuser, even if the device uses broadcast PReq, as the networks SSID can be guessed.

44 7 Conclusion

7.2 Future WorkIn this thesis, we have created a prototype implementation consisting of the Nexus 5,the TP-Link WN722N, and the Android application WifiAnalyzer. Being a prototype,there are still some bugs and stability issues that need to be fixed. However, there aresome features left to be implemented. The packet capture can be extended to evaluatemore types of packets, and identify more information on the packet itself, for examplecapability and encryption information of the AP from beacon frames. Packets generatedfrom SSID-Mixer could be tagged in order to identify them within our own capture andignore them for evaluation. The functionality of RSSI based tracking can be improved,as the calculated signal strength is not very accurate. Furthermore, the calculated valuefrom multiple devices can be used to triangulate a station, e. g., an attacker.

Creating a client-server-architecture is another way to extend the applications capabil-ities. This could be used for a centralized evaluation of captured packets, for exampleto send alerts of active Karma attacks to all connected clients. The SSID-Mixer alsoprofits of this feature, combining the information of multiple nodes allows the tool tocover a larger area. Additionally, it might be possible to send the processed data forSSID-Mixer to additional stations, which do not posses monitoring equipment themselves.As a result, unmodified smartphones might be able to participate as long as they run therelevant application.

We also entertain the idea of implementing the application the application on a low-costsingle-board-computer, for example the Raspberry Pi. This would allow us to create anaffordable solution for network monitoring, which keeps a focus on attacker-detection.The application could be extended with modules for different purposes. The packet sniffer,Karma-Detector, and SSID-Mixer were already created within this thesis. Further ideasinclude a detector for Rogue-APs, Address Resolution Protocol (ARP) spoofing attacksand a honeypot AP using Wired Equivalent Privacy (WEP) for encryption. Nearby userdevices could be alerted about the active attacks, while the offending MAC address couldbe automatically deauthenticated from all WLANs.

A Appendix

A.1 Acronymsadb Android Debug Bridge

ADT Android Developer Tools

AP (wireless) Access Point

ARP Address Resolution Protocol

apk Android Application Package

ASCII American Standard Code for Information Interchange

BSSID Basic Service Set Identification

CLI Command-line interface

CM CyanogenMod

DB Database

DeAuth Deauthentication (frame)

DHCP Dynamic Host Configuration Protocol

DoS Denial of Service

ESSID Extended Service Set Identification

ETSI European Telecommunications Standards Institute

GUI Graphical User Interface

IDE Integrated Development Environment

IP Internet Protocol

IT Information Technology

IEEE Institute of Electrical and Electronics Engineers

JDK Java Development Kit

LUT Lookup table

MAC Media Access Control (address)

MIC Message Integrity Code

46 A Appendix

MitM Man-in-the-middle

NDK Native Development Kit

NIC Network Interface Controller

OEM Original Equipment Manufacturer

OS Operating System

OSI Open Systems Interconnection (model)

OTG (USB) On-The-Go

PReq Probe Request (frame)

PResp Probe Reponse (frame)

PSK Pre-Shared Key

PNL Preferred Network List

RSSI Received Signal Strength Indicator

ROM Read Only Memory, also used to refer to custom OSs on smartphones.

SDK Software Development Kit

SQL Structured Query Language

SSID Service Set Identification

SSL Secure Sockets Layer

StGB Strafgesetzbuch (“Penal Code”)

TLS Transport Layer Security

TWRP Team Win Recovery Project

USB Universal Serial Bus

VM Virtual Machine

WEP Wired Equivalent Privacy

WLAN Wireless Local Area Network

WPA Wi-Fi Protected Access

A.2 Important Commands for Adb and Fastboot 47

A.2 Important Commands for Adb and Fastbootadb devices lists all the connected devices.

adb connect to connect to the device if “adb over network” is enabled. The latter is aunique feature of the CyanogenMod Custom-ROM.

adb root restarts the adb-daemon using root permissons.

adb remount remounts the /system partition on the device as writeable.

adb push $localPath $remotePath is used to copy a file from the computer to thesmartphone. To write to the /system partition, adb remount has to be executedbeforehand.

adb pull works similarly to adb push, it copies a file from the device to the computer.

adb install $pathToAPK installs an Android Application Package (apk)-file.

adb shell executes a single command on the device or starts the shell itself. Thiscommand proved to be very handy.

adb reboot [bootloader|recovery] reboots the device, optionally into the bootloader orrecovery program.

adb logcat (-s $tag) accesses the devices logs. By specifing a tag, one can filter theoutput.

fastboot oem unlock unlocks the bootloader for custom modifications. This is manda-tory for any modification shown in this thesis.

fastboot flash [boot|recovery] $pathToFile can be used to flash a partition image.Other partitions are system, data, cache.

fastboot erase [system|data|cache] recreates the specified partition. This is usefulbefore flashing a new OS.

48 A Appendix

A.3 Code Excerpts

1 int main(int argc,char **argv) {2 // 1. init device/interface, enable monitor mode3 if(system("modprobe ath9k_htc;")) {4 printf("Loading kernel modules failed.\n");5 exit(1);6 }78 char device[6] = "wlan1";9 char monitor_cmd[81];

10 snprintf(monitor_cmd, 81, "ifconfig %5s down;iwconfig %5s mode monitor;ifconfig %5s up", device,→˓ device, device);

11 if(system(monitor_cmd)) {12 printf("Monitor mode could not be started.\n");13 exit(1);14 }1516 // 2. pcap init/create17 char errbuf[PCAP_ERRBUF_SIZE];18 pcap_t *handle = pcap_create(device, errbuf);19 pcap_set_snaplen(handle, 65535);2021 if (handle == NULL) {22 fprintf(stderr, "Couldn’t open device %s: %s", device, errbuf);23 exit(1);24 }2526 // 3. pcap start27 pcap_activate(handle);28 // Capture 100 packets, packets processed by processPacket()29 pcap_loop(handle, 100, processPacket, NULL);3031 // cleanup32 pcap_close(handle);33 }3435 void processPacket(u_char *args, const struct pcap_pkthdr *header, const u_char *packet) {36 //identify the frame and print information37 }

Listing A.1: Sample code for initializing a scanner using libpcap (excerpt frompcapScanner-demo.c).

1 void initInterfaces() {2 //Load kernel module3 if(system("modprobe ath9k_htc;")) {4 printf("Loading kernel modules failed.\n");5 exit(1);6 }78 sleep(1);9 if(access("/sys/class/net/wlan1/", F_OK) != -1) {

10 // Interface exists -> temporary disable it11 if(system("ifconfig wlan1 down;")) {12 printf("Disabling WiFi-interfaces failed.\n");13 exit(1);14 }15 } else {16 // Interface doesn’t exist, enable interface to "activate" it then temporary disable it

A.3 Code Excerpts 49

17 system("ifconfig wlan1 up; ifconfig wlan1 down;");18 }1920 sleep(1);21 // Set managed mode on main interface22 if(system("iwconfig wlan1 mode managed;")) {23 printf("Setting Managed Mode on wlan1 failed.\n");24 exit(1);25 }2627 if(access("/sys/class/net/pcap_mon0/", F_OK) != -1) {28 // Monitoring interface already exists29 if(system("iw dev pcap_mon0 del;")) {30 printf("Deleting virtual interface failed.\n");31 exit(1);32 }33 }3435 sleep(1);36 // (Re)create monitoring interface37 if(system("iw phy phy1 interface add pcap_mon0 type monitor;")) {38 printf("Creating virtual interface failed.\n");39 exit(1);40 }4142 sleep(1);43 // Enable all interfaces, set monitor interface to channel 644 if(system("ifconfig wlan1 up; iwconfig pcap_mon0 channel 6; ifconfig pcap_mon0 up;")) {45 printf("Enabling WiFi-interfaces failed.\n");46 exit(1);47 }48 }

Listing A.2: Initializing the wireless interface.

1 # ifconfig $interface down2 # ip link set dev $interface address $newMAC3 # ifconfig $interface up

Listing A.3: Changing an interface’s MAC address.

50 A Appendix

A.4 SQL Commands Used for Data Processing

1 SELECT source_address,2 COUNT(CASE type WHEN "Beacon" THEN 1 ELSE NULL END) AS beacon_count,3 COUNT(CASE type WHEN "Probe Response" THEN 1 ELSE NULL END) AS probeResp_count,4 COUNT(CASE type WHEN "Probe Request" THEN 1 ELSE NULL END) AS probeReq_count,5 COUNT(CASE type WHEN "Data" THEN 1 ELSE NULL END) AS data_count,6 COUNT(CASE type WHEN "DeAuth" THEN 1 ELSE NULL END) AS deAuth_count,7 COUNT(*) AS total_count8 FROM frames9 GROUP BY source_address

10 ORDER BY total_count DESC

Listing A.4: Network Overview.

1 SELECT ssid,2 COUNT(CASE type WHEN "Beacon" THEN 1 ELSE NULL END) AS beacon_count,3 COUNT(CASE type WHEN "Probe Response" THEN 1 ELSE NULL END) AS probeResp_count,4 COUNT(CASE type WHEN "Beacon" THEN 1 WHEN "Probe Response" THEN 1 ELSE NULL END) AS total_count5 FROM frames6 GROUP BY ssid7 HAVING total_count > 08 ORDER BY total_count DESC

Listing A.5: Available Networks.

1 SELECT ssid,2 COUNT(distinct source_address) AS mac_count, COUNT(ssid) AS probeReq_count3 FROM frames4 WHERE type = "Probe Request"5 GROUP BY ssid6 HAVING probeReq_count > 07 ORDER BY probeReq_count DESC

Listing A.6: Requested Networks.

1 SELECT source_address,2 COUNT(CASE ssid WHEN "Broadcast" THEN 1 ELSE NULL END) AS broadcast_count,3 COUNT(CASE ssid WHEN "Broadcast" THEN NULL ELSE 1 END) AS directed_count,4 COUNT(*) AS total_count5 FROM frames6 WHERE type="Probe Request"7 GROUP BY source_address8 ORDER BY total_count DESC

Listing A.7: Broadcast and directed PReqs per station.

1 --the "ORDER BY"-clause defines the used mode.2 SELECT source_address,3 COUNT(ssid) as PNL,4 DATETIME(l_activity/1000, ’unixepoch’, ’localtime’) AS last_activity5 FROM (6 SELECT source_address,7 ssid,8 MAX(timestamp) as l_activity9 FROM frames

10 WHERE ssid != "Broadcast" AND type="Probe Request"11 GROUP BY source_address, ssid

A.4 SQL Commands Used for Data Processing 51

12 )13 GROUP BY source_address14 HAVING last_activity > DATETIME(’now’, ’-15 minutes’, ’localtime’)15 ORDER BY PNL DESC16 LIMIT 10

Listing A.8: Recently active clients.

1 --the "ORDER BY"-clause defines the used mode.2 SELECT ssid,3 COUNT(source_address) as uniqueDevices,4 DATETIME(l_activity/1000, ’unixepoch’, ’localtime’) AS last_activity5 FROM (6 SELECT ssid,7 source_address,8 MAX(timestamp) as l_activity9 FROM frames

10 WHERE ssid != "Broadcast" AND type="Probe Request"11 GROUP BY ssid, source_address12 )13 GROUP BY ssid14 HAVING last_activity > DATETIME(’now’, ’-15 minutes’, ’localtime’)15 ORDER BY uniqueDevices DESC16 LIMIT 10

Listing A.9: Recently active networks.

1 SELECT frames.source_address,2 frames.last_activity,3 sources.nickname,4 sources.packets_sent,5 sources.is_ap,6 sources.is_evil7 FROM (8 SELECT source_address,9 DATETIME(MAX(timestamp)/1000, ’unixepoch’, ’localtime’) AS last_activity

10 FROM frames11 GROUP BY source_address12 HAVING last_activity > DATETIME(’now’, ’-15 minutes’, ’localtime’)13 ) AS frames1415 INNER JOIN sources on frames.source_address = sources.src16 WHERE sources.is_ap == 117 ORDER BY frames.last_activity DESC

Listing A.10: Recently active APs.

1 SELECT frames.*,2 sources.nickname,3 sources.packets_sent,4 sources.is_ap,5 sources.is_evil6 FROM (7 SELECT source_address,8 DATETIME(MAX(timestamp)/1000, ’unixepoch’, ’localtime’) AS last_activity9 FROM frames

10 WHERE (source_address = @sMAC OR destination_address = @sMAC)11 GROUP BY source_address1213 UNION

52 A Appendix

1415 SELECT destination_address,16 DATETIME(MAX(timestamp)/1000, ’unixepoch’, ’localtime’) AS last_activity17 FROM frames18 WHERE source_address = @sMAC OR destination_address = @sMAC19 GROUP BY destination_address20 ) AS frames2122 INNER JOIN sources ON frames.source_address = sources.src2324 WHERE frames.source_address != "FF:FF:FF:FF:FF:FF"25 AND frames.source_address != "00:00:00:00:00:00"26 AND frames.source_address != @sMAC27 AND frames.last_activity > DATETIME(’now’, ’-5 minutes’, ’localtime’)2829 GROUP BY source_address30 ORDER BY last_activity DESC

Listing A.11: Get opposite parties of a station.

A.4.1 Queries used for Evaluation

1 SELECT "name" AS dataset,2 COUNT(CASE type WHEN "Beacon" THEN 1 ELSE NULL END) AS beacon_count,3 COUNT(CASE type WHEN "Probe Response" THEN 1 ELSE NULL END) AS probeResp_count,4 COUNT(CASE type WHEN "Probe Request" THEN 1 ELSE NULL END) AS probeReq_count,5 COUNT(CASE type WHEN "Data" THEN 1 ELSE NULL END) AS data_count,6 COUNT(CASE type WHEN "DeAuth" THEN 1 ELSE NULL END) AS data_count,7 COUNT(*) AS total_count8 FROM frames

Listing A.12: General information on dataset.

1 SELECT ssid, count(source_address) as uniqueDevices2 FROM (SELECT ssid, source_address3 FROM frames4 WHERE ssid != "Broadcast" AND type="Probe Request"5 GROUP BY ssid, source_address6 )7 GROUP BY ssid8 ORDER by uniqueDevices DESC

Listing A.13: Top SSIDs and unique clients.

1 SELECT source_address, count(ssid) as PNL2 FROM (3 SELECT source_address, ssid4 FROM frames5 WHERE ssid != "Broadcast" AND type="Probe Request"6 GROUP BY source_address, ssid7 )8 GROUP BY source_address9 ORDER BY PNL DESC

Listing A.14: PNL size and NIC vendor per station.

A.4 SQL Commands Used for Data Processing 53

1 SELECT AVG(strftime("%s", last_activity) - strftime("%s", first_activity)) as avg_time2 FROM (3 SELECT source_address,4 COUNT(CASE type WHEN "Probe Request" THEN 1 ELSE NULL END) AS probeReq_count,5 TIME(MIN(timestamp)/1000, ’unixepoch’, ’localtime’) AS first_activity,6 TIME(MAX(timestamp)/1000, ’unixepoch’, ’localtime’) AS last_activity7 FROM frames8 WHERE source_address != "FF:FF:FF:FF:FF:FF"9 AND source_address != "00:00:00:00:00:00"

10 GROUP BY source_address11 HAVING probeReq_count>012 )

Listing A.15: Average duration of stay of all stations.

54 A Appendix

A.5 Configuration Files

1 # Define interface2 interface=wlan13 # Select driver4 driver=nl802115 # Set access point name6 ssid=DEMO-Hotspot7 # Set access point harware mode to 802.11g8 hw_mode=g9 # Set WIFI channel (can be easily changed)

10 channel=611 # Enable WPA2 only (1 for WPA, 2 for WPA2, 3 for WPA + WPA2), needs wpa_supplicant12 #wpa=213 #wpa_passphrase=mypassword

Listing A.16: Configuration file for hostapd.

1 # Bind to only one interface2 bind-interfaces3 # Choose interface for binding4 interface=wlan15 # Specify range of IP addresses for DHCP leasses6 dhcp-range=192.168.150.2,192.168.150.107 # DNS Server8 server=8.8.8.8

Listing A.17: Configuration file for dnsmasq.

A.6 Miscellaneous 55

A.6 Miscellaneous

1 # iwlist wlan1 scan (ssid $ssid)23 Example Output (shortened to one result):4 wlan1 Scan completed :5 Cell 02 - Address: 00:1E:E5:63:F1:A06 Channel:107 Frequency:2.457 GHz (Channel 10)8 Quality=62/70 Signal level=-48 dBm9 Encryption key:on

10 ESSID:"BYOB"11 Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 18 Mb/s12 24 Mb/s; 36 Mb/s; 54 Mb/s13 Bit Rates:6 Mb/s; 9 Mb/s; 12 Mb/s; 48 Mb/s14 Mode:Master15 Extra:tsf=000000000550bab616 Extra: Last beacon: 90ms ago17 IE: Unknown: 000442594F4218 IE: Unknown: 010882848B962430486C19 IE: Unknown: 03010A20 IE: Unknown: 2A010021 IE: Unknown: 2F010022 IE: IEEE 802.11i/WPA2 Version 123 Group Cipher : CCMP24 Pairwise Ciphers (1) : CCMP25 Authentication Suites (1) : PSK26 IE: Unknown: 32040C12186027 IE: Unknown: 2D1A1C181AFFFF00000000000000000000000000000000000000000028 IE: Unknown: 3D160A08040000000000000000000000000000000000000029 IE: Unknown: 7F010130 IE: Unknown: DD710050F204104A0001101044000102103B00010310470010001EE563F19E001E

→˓ E563F19E070000001021000C4C696E6B73797320496E632E102300075752543136304E1024000776312→˓ E322E3131104200033030311054000800060050F2040001101100075752543136304E100800020084

31 IE: Unknown: DD090010180203F401000032 IE: Unknown: DD180050F2020101000003A4000027A4000042435E0062322F0033 IE: Unknown: DD1E00904C331C181AFFFF00000000000000000000000000000000000000000034 IE: Unknown: DD1A00904C340A080400000000000000000000000000000000000000

Listing A.18: Scanning for WLANs using iwlist.

1 wlan1: STA bc:f5:ac:f6:30:50 IEEE 802.11: authenticated2 wlan1: STA bc:f5:ac:f6:30:50 IEEE 802.11: associated (aid 1)3 wlan1: STA bc:f5:ac:f6:30:50 IEEE 802.11: disassociated4 wlan1: STA bc:f5:ac:f6:30:50 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)

Listing A.19: Example log of hostapd.

1 dnsmasq: started, version 2.51 cachesize 1502 dnsmasq: compile time options: no-IPv6 GNU-getopt no-DBus no-I18N DHCP no-scripts no-TFTP3 dnsmasq-dhcp: DHCP, IP range 192.168.150.2 -- 192.168.150.10, lease time 1h4 dnsmasq: using nameserver 8.8.8.8#535 dnsmasq: read /etc/hosts - 1 addresses6 dnsmasq-dhcp: DHCPREQUEST(wlan1) 192.168.10.110 bc:f5:ac:f6:30:507 dnsmasq-dhcp: DHCPNAK(wlan1) 192.168.10.110 bc:f5:ac:f6:30:50 wrong address8 dnsmasq-dhcp: DHCPDISCOVER(wlan1) bc:f5:ac:f6:30:509 dnsmasq-dhcp: DHCPOFFER(wlan1) 192.168.150.5 bc:f5:ac:f6:30:50

10 dnsmasq-dhcp: DHCPREQUEST(wlan1) 192.168.150.5 bc:f5:ac:f6:30:5011 dnsmasq-dhcp: DHCPACK(wlan1) 192.168.150.5 bc:f5:ac:f6:30:50 android-24ba22feba605a35

Listing A.20: Example log of dnsmasq.

1 #! /bin/bash23 adb connect $14 sleep 15 adb root6 sleep 17 adb connect $18 sleep 19 adb remount

10 sleep 111 adb connect $1

Listing A.21: Helper script for adb connect.

1 #! /bin/bash23 adb push $1 $245 echo $1 "pushed on:"6 date

Listing A.22: Helper script for adb push.

1 #! /bin/bash23 if [[ -z $1 ]]; then4 echo "No filename supplied!"5 exit6 fi7 $NDKTC/bin/arm-linux-androideabi-gcc-4.9 $1 -static -o ~/Desktop/${1::-2} -I./ -L./ -lpcap -

→˓ pthread8 mv ~/Desktop/${1::-2} /mnt/hgfs/WiFi-Attacks/#tempdir9 echo $1 "last compiled on:"

10 date

Listing A.23: Helper script for Android compilation via gcc.

List of Algorithms

4.1.1 Karma-Detector (Pseudocode) . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.2.1 SSID-Mixer (Pseudocode) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

List of Figures

2.1 Comparing Broadcast and Directed Probe Requests. . . . . . . . . . . . . 72.2 The WLAN authentication and association process. . . . . . . . . . . . . 72.3 The Wireshark user interface in “live capture”-mode. . . . . . . . . . . . . 102.4 Hak5’s WiFi Pineapple Mark V . . . . . . . . . . . . . . . . . . . . . . . . 12

4.1 Schematic representation of the Karma attack. . . . . . . . . . . . . . . . 184.2 Web interface of the Jasager implementation, 2008. . . . . . . . . . . . . . 194.3 Comparing captured Probe Requests with SSID-Mixer enabled and disabled. 22

5.1 The devices used for this thesis. . . . . . . . . . . . . . . . . . . . . . . . . 265.2 The menuconfig tool to configure the Android kernel. . . . . . . . . . . . . 295.3 The Nexus 5 in fastboot- and recovery-mode. . . . . . . . . . . . . . . . . . 305.4 The main interface of the application WifiAnalyzer and the used icons. . . 335.5 The database structure of the application WifiAnalyzer. . . . . . . . . . . 345.6 The GUI in the application WifiAnalyzer showing detailed information on

a selected station. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.7 The main interface of WifiAnalyzer when a Karma-attack is detected. . . 36

6.1 The length of the PNL across all datasets. . . . . . . . . . . . . . . . . . . 416.2 The top 5 vendors, comparing all PReqs and only directed PReqs. . . . . 41

List of Listings

4.1 Syntax for Deauthentication using aireplay-ng . . . . . . . . . . . . . . . . 18

5.1 Example content for the git configuration file (~/.gitconfig). . . . . . . 285.2 Commands to build the complete CM OS and only its kernel. . . . . . . . 285.3 Accessing the tool menuconfig to modify the kernel . . . . . . . . . . . . . 295.4 Additional kernel options activated in menuconfig . . . . . . . . . . . . . . 295.5 Enabling IP-forwarding and configuring the firewall. . . . . . . . . . . . . 375.6 Starting the hotspot. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

A.1 Sample code for initializing a scanner using libpcap. . . . . . . . . . . . . . 48A.2 Initializing the wireless interface. . . . . . . . . . . . . . . . . . . . . . . . 48A.3 Changing an interface’s MAC address. . . . . . . . . . . . . . . . . . . . . 49A.4 Network Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50A.5 Available Networks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50A.6 Requested Networks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50A.7 Broadcast and directed PReqs per station. . . . . . . . . . . . . . . . . . . 50A.8 Recently active clients. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50A.9 Recently active networks. . . . . . . . . . . . . . . . . . . . . . . . . . . . 51A.10 Recently active APs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51A.11 Get opposite parties of a station. . . . . . . . . . . . . . . . . . . . . . . . 51A.12 General information on dataset. . . . . . . . . . . . . . . . . . . . . . . . . 52A.13 Top SSIDs and unique clients. . . . . . . . . . . . . . . . . . . . . . . . . . 52A.14 PNL size and NIC vendor per station. . . . . . . . . . . . . . . . . . . . . 52A.15 Average duration of stay of all stations. . . . . . . . . . . . . . . . . . . . 53A.16 Configuration file for hostapd. . . . . . . . . . . . . . . . . . . . . . . . . . 54A.17 Configuration file for dnsmasq. . . . . . . . . . . . . . . . . . . . . . . . . 54A.18 Scanning for WLANs using iwlist. . . . . . . . . . . . . . . . . . . . . . 55A.19 Example log of hostapd. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55A.20 Example log of dnsmasq. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55A.21 Helper script for adb connect. . . . . . . . . . . . . . . . . . . . . . . . . . 56A.22 Helper script for adb push. . . . . . . . . . . . . . . . . . . . . . . . . . . . 56A.23 Helper script for Android compilation via gcc. . . . . . . . . . . . . . . . . 56

List of Tables

6.1 Overview of the measurements performed at three locations. . . . . . . . . 40

Bibliography

[BEM+13] Marco V. Barbera, Alessandro Epasto, Alessandro Mei, Vasile C. Perta,and Julinda Stefa. Signals from the crowd: uncovering social relationshipsthrough smartphone probes. In Proceedings of the 2013 conference on Internetmeasurement conference, pages 265–276. ACM, 2013.

[BGM08] Kevin Bauer, Harold Gonzales, and Damon McCoy. Mitigating evil twin at-tacks in 802.11. In Performance, Computing and Communications Conference,2008. IPCCC 2008. IEEE International, pages 513–516. IEEE, 2008.

[CKB12] Mathieu Cunche, Mohamed Ali Kaafar, and Roksana Boreli. I know who youwill meet this evening! Linking wireless devices using Wi-Fi probe requests.In World of Wireless, Mobile and Multimedia Networks (WoWMoM), 2012IEEE International Symposium on a, pages 1–9. IEEE, 2012.

[CMC+12] Ningning Cheng, Prasant Mohapatra, Mathieu Cunche, Mohamed Ali Kaafar,Roksana Boreli, V Srikanth, et al. Inferring User Relationship from Hid-den Information in WLANs. In MILCOM-IEEE Military CommunicationsConference-2012, 2012.

[Cun13] Mathieu Cunche. I know your MAC Address: Targeted tracking of individualusing Wi-Fi. Journal of Computer Virology and Hacking Techniques, pages1–9, 2013.

[DW14] Ronald Eikenberg David Wischnjak. “Auf Schritt und Tritt”. c’t, (21):158–161,2014.

[DZM05] Dino A Dai Zovi and Shane A Macaulay. Attacking automatic wireless networkselection. In Information Assurance Workshop, 2005. IAW’05. Proceedingsfrom the Sixth Annual IEEE SMC, pages 365–372. IEEE, 2005.

[GGP+07] Ben Greenstein, Ramakrishna Gummadi, Jeffrey Pang, Mike Y Chen, Ta-dayoshi Kohno, Srinivasan Seshan, and David Wetherall. Can Ferris BuellerStill Have His Day Off? Protecting Privacy in the Wireless Era. In HotOS,2007.

[Hen15] Henrik Kroll. Sound of Silence: Wi-Fi Eavesdropping and Traffic Analysis onAndroid. Bachelor’s Thesis, March 2015.

[IdV14] Dominic White Ian de Villiers. Manna from Heaven: Improvements in RogueAP Attacks. In Presentation at DEF CON 22, 2014.

62 Bibliography

[ME12] ABM Musa and Jakob Eriksson. Tracking Unmodified Smartphones UsingWi-Fi Monitors. In Proceedings of the 10th ACM Conference on EmbeddedNetwork Sensor Systems, pages 281–294. ACM, 2012.

[Rec] J. Rech. Wireless LANs: 802.11-WLAN-Technologie und praktische Umset-zung im Detail. 4th edition.

[SCW+11] Yi-Sheng Shiu, Shih Yu Chang, Hsiao-Chun Wu, Scott C.-H. Huang, andHsiao-Hwa Chen. Physical Layer Security in Wireless Networks: A Tutorial.IEEE Wireless Commun., 18(2):66–74, 2011.