asset-light wireless security as a service
TRANSCRIPT
Asset-Light Wireless Security as a Service
by
Craig Odell
A master’s project report submitted to the Graduate Faculty of the
University of Colorado at Colorado Springs
in partial fulfillment of the requirements of
Masters of Science
Department of Computer Science
2014
ii
© Copyright by Craig Odell 2014
All Rights Reserved
The project report for Masters of Science degree by
Craig Odell
has been approved for the
Department of Computer Science
by
_______________________
Terrance E. Boult
______________________
Chuan Yue
______________________
Jia Rao
_______________
Date
iv
Abstract
In a world of increasing cyber security threats that is becoming dominated by
wireless access mediums, the need for tools and systems to protect the wireless space is
evident. Many providers have created solutions in the wireless security space to fill this
need; however, all of these solutions make key assumptions about the cost, market, and
target customers for the solution. By leveraging disruptive technologies that have, and
are, changing the world as we know it, this project recreates the state of the art
commercial solutions in an asset-light way that allows anyone to protect their wireless
assets and protect themselves in a rapidly changing world.
v
Table of Contents
1 Abstract ................................................................................................................................... iv
2 Table of Contents ..................................................................................................................... v
3 List of Tables ........................................................................................................................... ix
4 List of Figures ........................................................................................................................... x
5 Introduction ............................................................................................................................. 1
6 Background .............................................................................................................................. 4
6.1 State of the Art ................................................................................................................. 4
6.2 Motorola AirDefense ....................................................................................................... 5
6.3 AirTight ............................................................................................................................. 6
6.4 AirMagnet ...................................................................................................................... 10
6.5 Disruptive Technology. .................................................................................................. 12
6.6 Asset-Light Orientation .................................................................................................. 15
7 Problem .................................................................................................................................. 19
8 Idea ........................................................................................................................................ 20
9 Design ..................................................................................................................................... 22
9.1 Cloud Web Application .................................................................................................. 24
9.2 Cloud Management Application .................................................................................... 24
9.3 Probes ............................................................................................................................ 25
9.4 System Functionality ...................................................................................................... 26
9.5 Defense .......................................................................................................................... 26
9.6 Offense ........................................................................................................................... 27
10 Implementation ................................................................................................................. 30
10.1 Cloud Web Application .................................................................................................. 32
10.1.1 Marketing Information........................................................................................... 33
10.1.2 Sign Up ................................................................................................................... 33
10.1.3 Password Reset ...................................................................................................... 36
10.1.4 Sign In ..................................................................................................................... 38
10.1.5 Session Management ............................................................................................. 40
10.1.6 Use of PassportJs ................................................................................................... 40
vi
10.1.7 Probe Management ............................................................................................... 40
10.1.8 Probe Claiming ....................................................................................................... 41
10.1.9 Protection Setup .................................................................................................... 45
10.1.10 Account Settings ................................................................................................ 47
10.1.11 Scans .................................................................................................................. 49
10.1.12 Events ................................................................................................................. 51
10.1.13 Protection Information ...................................................................................... 53
10.1.14 Attacks................................................................................................................ 53
10.1.15 Attack Information ............................................................................................. 56
10.1.16 Dashboard .......................................................................................................... 56
10.1.17 Sign Out .............................................................................................................. 60
10.1.18 Responsive User Interface ................................................................................. 60
10.1.19 Mobile-Friendly User Interface .......................................................................... 61
10.2 Cloud Management Application .................................................................................... 64
10.2.1 Probe Interaction and Data Collection................................................................... 65
10.2.2 Automated Probe Updates .................................................................................... 67
10.2.3 Event Detection...................................................................................................... 68
10.2.4 User Notification .................................................................................................... 68
10.3 Probe .............................................................................................................................. 69
10.3.1 Setup ...................................................................................................................... 70
10.3.2 Data Collection and Submission............................................................................. 71
10.3.3 Cloud Command Response .................................................................................... 71
10.3.4 Daemonization ....................................................................................................... 72
10.3.5 Attacks.................................................................................................................... 72
10.3.6 Protection .............................................................................................................. 73
10.3.7 Vendor Lookup ....................................................................................................... 74
10.3.8 Data Usage and Memory Usage............................................................................. 75
10.3.9 Probe Update ......................................................................................................... 76
10.4 System Functionality ...................................................................................................... 76
10.4.1 Attack Suite and Offensive Functionality ............................................................... 77
10.4.2 Denial of Service Attack ......................................................................................... 78
10.4.3 Client, Access Point, or Network-Targeted Denial of Service ................................ 81
vii
10.4.4 Vendor Targeted Denial of Service ........................................................................ 82
10.4.5 Channel Denial of Service Attack ........................................................................... 83
10.4.6 ‘Boom’ Denial of Service Attack ............................................................................. 83
10.4.7 SSID Bomb .............................................................................................................. 84
10.4.8 WEP Crack .............................................................................................................. 86
10.4.9 WPA Handshake Acquisition .................................................................................. 87
10.4.10 Defense and Protection Functionality ............................................................... 88
10.4.11 Rogue Access Point Detection (New Access Point Detection) ........................... 89
10.4.12 Denial of Service Detection ................................................................................ 91
10.4.13 Misconfiguration Detection ............................................................................... 92
10.4.14 Evil Twin Detection ............................................................................................ 92
10.4.15 Man in the Middle Attack Detection ................................................................. 93
10.4.16 Performance Sampling ....................................................................................... 94
11 Results ................................................................................................................................ 96
11.1 Attack Performance ....................................................................................................... 96
11.1.1 Denial of Service..................................................................................................... 96
11.1.2 SSID Bomb .............................................................................................................. 97
11.1.3 WEP Crack .............................................................................................................. 98
11.1.4 WPA Handshake Acquisition .................................................................................. 98
11.1.5 Protection Performance ......................................................................................... 99
11.1.6 Denial of Service Detection .................................................................................. 100
11.1.7 Man in the Middle Detection ............................................................................... 100
11.1.8 Functionality Comparison .................................................................................... 101
11.1.9 Market and Cost Comparison .............................................................................. 103
12 Future Work ..................................................................................................................... 106
12.1 Data Protection Concerns Mitigation .......................................................................... 106
12.2 Future Attacks .............................................................................................................. 108
12.3 Go to Market Strategy ................................................................................................. 109
12.4 Mobile Application ....................................................................................................... 109
13 Conclusion ........................................................................................................................ 111
14 References ....................................................................................................................... 112
15 For Appendices Please See Separate Appendix Document ............................................. 118
viii
ix
List of Tables
Table 1: Feature Comparison ....................................................................................................... 102
Table 2: Commercial Comparison ................................................................................................ 104
x
List of Figures
Figure 1: Re-Imagination of Everything ......................................................................................... 14
Figure 2: Asset-Heavy vs Asset-Light ............................................................................................. 17
Figure 3: System Architecture ........................................................................................................ 23
Figure 4: Sign Up ............................................................................................................................ 35
Figure 5: Password Reset ............................................................................................................... 37
Figure 6: Sign In .............................................................................................................................. 39
Figure 7: Claim Sequence ............................................................................................................... 43
Figure 8: Unclaim ........................................................................................................................... 44
Figure 9: Protection Setup ............................................................................................................. 46
Figure 10: User Information ........................................................................................................... 48
Figure 11: Change Password .......................................................................................................... 48
Figure 12: Notification Settings ..................................................................................................... 48
Figure 13: Scans Interface .............................................................................................................. 50
Figure 14: Events Interface ............................................................................................................ 52
Figure 15: Attacks Interface ........................................................................................................... 55
Figure 16: Dashboard Summary Interface ..................................................................................... 58
Figure 17: Dashboard Condensed Interface .................................................................................. 59
Figure 18: Example Desktop View of the Scans Interface ............................................................. 63
Figure 19: Example Mobile View of the Scans Interface ............................................................... 63
Figure 20: Association State Diagram ............................................................................................ 79
Figure 21: Example SSID Bomb ...................................................................................................... 85
1
1 Introduction
In December of 2013, more than 110 million Target customers were impacted by an
attack stealing credit card information [1]. After the initial shock of a security breach of this
magnitude subsides, the first question that enters the minds of those impacted or interested is
how did the attackers carry out their attack? While investigations on what attackers did to
compromise Target’s point-of-sale systems remain ongoing, the fundamental question that is
asked with respect to any attack is: how did the attackers gain access to the target system? In
this case, the victimized system consisted of the point-of-sale devices used to carry out
customer transactions [2]. More specifically, the attackers were able to distribute malware onto
the point-of-sale devices via a centralized server or set of servers. This again begs the question
of how they gained access to the centralized server(s). Looking further back, when 47.5 million
credit cards were stolen from TJ Maxx in 2007 (previously thought to be the largest hack ever),
the first vulnerability that the attackers exploited was an insecure wireless network [3, 4].
To anyone skilled in the art of security, they know, and can likely list, the many ways
that attackers could compromise a server, machine, etc. Examples might include direct inside
access, penetrating or bypassing firewalls, etc. A common element of all of these attack
techniques requires, implicitly or explicitly, access to the target system’s network. In other
words, the fundamental problem that attacker(s) must solve before compromising a server (for
example) is: gaining access to the private network so that one can compromise the target server
(or system). While gaining access to a network takes on many forms, one of the easiest, most
effective, most cost-effective, fail-proof, and well-known attack methods to gain access to a
private network is via an unauthorized wireless connection (typically this is a WLAN/Wi-
Fi™/IEEE802.11 connection and henceforth in this report the term wireless refers to this typical
case) [5,6].
2
This unauthorized wireless connection can also take many forms, but the most
ubiquitous form of attack is a rogue access point that is connected into the core of the network.
A rogue access point can provide attackers an easy way to bypass altogether network firewalls,
network intrusion detection systems, and other protection systems, while often appearing to be
an unrelated access point (perhaps from a neighboring facility). Rogue access points are thusly
named as they are unauthorized connectors into the private network.
Rogue access points and other wireless vulnerabilities are the primary reason why
companies spend millions of dollars every year on tools and monitoring systems that can detect
and mitigate these types of security problems. Likewise, these types of vulnerabilities are the
same reason why high-security facilities (for example high-security government securities)
disallow all wireless devices entirely and similarly pay large sums of money for systems and tools
that can determine whether or not the disallowance of wireless activity is being followed.
Underlying all of the issues described above is an underlying premise: wireless
communication has fundamental insecurities. What does this mean? It means that even as the
security protocols and techniques have improved dramatically for wireless communication, the
principal reality of using a shared medium create scenarios that have fundamental security
limitations.
Despite the insecurities and performance issues that arise when using a shared
communication medium, the convenience of wireless and ever-improving techniques for
wireless communication are driving strong adoption, even to the point where it is replacing
altogether the installation of copper Ethernet drops to cubicles in office buildings [7].
Furthermore, for residential use, small business use, and even medium business use, wireless is
and has become the primary choice for data communication on the network edge. Wireless
3
communication is expected to grow in adoption and use, particularly as the possible data
transfer rates continue to grow and even exceed 1Gbps [5].
The growth and adoption of wireless as an access layer medium coupled with the
insecurities that exist alongside that growth provides a definitive imperative, need, and
reasoning for the devices and systems developed and purchased that assist in mitigating
security and performance problems found in this domain. In the following section, the state of
the art with respect to wireless security is outlined in detail. While the state of the art is
extraordinarily powerful with respect to mitigating these insecurities, there are shortcomings
that provide the underlying basis and need for a new, supplemental solution. Outlined in detail
below, two of the primary shortcomings of the existing state of the art are as follows: first, the
state of the art does not adequately account for disruptive technologies such as mobile and
cloud. Second, the state of the art assumes a specific cost and therefore price-point that
neglects the majority of the customers that require a wireless protection system. The project
discussed in this report addresses these shortcomings.
4
2 Background
2.1 State of the Art
As stated above, there is a clear need for solutions to protect one’s network from
wireless threats and much research has been done in this area to improve it over the past
decade. Some examples of research in this area include advanced rogue access point detection
techniques [8], intrusion detection enhancements [9], signature-based threat detection and
mitigation [10], denial of service detection [11], etc. [12]. All of the research in this area has
greatly improved the state of the art and improved the overall security of wireless systems.
Similarly, all of these advancements have been incorporated into three primary commercial
solutions in this area that are outlined in detail in the following subsections. Since this project
attempts to enhance the state of the art in a primarily commercial sense, the state of the art will
henceforth refer to the state of the art techniques that are incorporated into the market leading
product solutions (in other words, future references to the state of the art refer to the
commercial solutions which implicitly include the state of the art from a technical standpoint).
The three market-leading commercial solutions that are considered the best solutions in this
area are as follows: AirMagnet, AirTight, and Motorola AirDefense. The solutions provided by
these three companies are considered the best in the business and provide a high standard for
the state of the art. The solutions are considered the state of the art and the best in the
business both due to their combined dominance of the market and due to their ownership of
the technical intellectual property. While these three solutions provide very similar products –
so much so that it is difficult to differentiate at a surface level – the following subsections
outline the specifics related to each solution.
5
2.2 Motorola AirDefense
AirDefense is marketed as a holistic network services management for WLAN [13]. As
stated by Motorola: Motorola’s AirDefense Services Platform (ADSP) simplifies the
management, monitoring, and protection of your WLAN networks. The platform supports four
key functions – security and compliance, network assurance, infrastructure management, and
proximity awareness and analytics – within a modular architecture to maximize deployment
flexibility and minimize the cost of implementation [14]. This solution uses probes deployed
throughout the customer network that monitor and detect management, performance, and
security issues. The probes report back to a centralized server that resides on the private
network usually within some private data center. Important for the sake of this project, that
server is owned and managed by the user who has purchased the AirDefense solution thus
implying a high-level of sophistication when it comes to the users of the solution [14]. Another
important note with respect to this solution relates to the hardware and software requirements
of the edge sensors or probes. These probes are designed to be stand-alone and operate
without needing a centralized controller. While this architecture makes sense in many scenarios,
this approach has a number of shortcomings that align themselves with an asset-heavy
(meaning the architecture requires expensive and powerful probes) topology [14]. The probes,
and the overall solution, provide the following with respect to wireless security:
Rogue detection and mitigation
Policy enforcement
Regulatory enforcement
6
Intrusion detection and prevention
Unusual network activity detection
Vulnerability assessment
This solution provides a number of other features to help private network owners manage their
networks such as:
Centralized WLAN management
Network assurance
Network availability
RF problem detection
Spectrum analysis
Client connection trouble shooting
This strong set of features enables the users of this solution to not only protect their
network but manage and troubleshoot powerfully. The solution is backed by 28 patents that
claim to be the earliest and broadest in the wireless security space [14].
2.3 AirTight
Founded in 2003, AirTight Networks is a strong solution provider in the wireless security
and technology domain claiming to be one of the first to provide wireless intrusion detection
and prevention [9, 10]. AirTight takes an interesting approach to wireless security that differs
from their competition: chiefly they provide a cloud-hosted solution tag-lined: Secure Cloud-
Managed Wi-Fi [16]. Similar to AirDefense, the AirTight solution utilizes probes deployed
7
throughout the customer’s network that monitor, detect, and mitigate problems. AirTight
provides a similar feature set to AirDefense and AirMagnet including:
Rogue detection and mitigation – claiming no false positives
Policy deployment
Intrusion detection and prevention
Device classification and tracking
Claiming 25 backing patents (or pending patent applications) to the AirTight solution,
AirTight provides a unique solution via its cloud-managed service. Interestingly, AirTight claims a
superior rogue access point detection mechanism called a “marker packet.” Simply stated, this
technique attempts to differentiate between neighboring access points (i.e. benign access
points that exist on an unrelated network) and access points that are connected to the same,
owned, private network [16]. It does this by transmitting “marked” packets onto the wired-side
of the private network (i.e. via the Ethernet link into the network) [17]. These “marked” packets
are then carried through the local area network and presumably will be transmitted by wireless
access points that are connected to the same local area network onto the wireless medium.
Thus, after transmitting one or more “marked” packets, the probe can then watch the wireless
medium to see if the suspected access point transmits the “marked” packet(s). Though not
clearly stated in the patent, presumably the solution has various “marking” techniques including
ones that account for encrypted traffic over the wireless medium (as will almost always be the
case). I.e. the “marked” packets are likely padded with some uniquely identifying length such
that the listening probe can determine that the packet is marked even when the probe cannot
decrypt the data segment of the frame. While this patented technique is indeed clever and has
8
proven effective even outside the wireless security domain, it makes some fundamental
assumptions that are altogether incorrect.
To illustrate the incorrect assumptions of this detection technique, let us assume that a
rogue access point is connected to the private network that is being protected and that the
probe has transmitted one or more “marked” packets on to the wired local area network. First,
even if you transmit broadcast frames onto the local area network, there is no definite way that
those frames will reach the attached rogue access point. In other words, this assumes that the
probe and the rogue access point are on the same subnet and therefore same broadcast
domain. This is a strong assumption that has serious deployment implications. Most
significantly, this implies that at least one probe exists on every subnet throughout the private
network. Furthermore, this implies that either all the subnets are geographically centralized (i.e.
a single probe will be able to monitor the wireless medium for all devices that may be
connected to that particular subnet) or that multiple probes must be deployed per subnet such
that all devices are covered. Furthermore, it mandates that the wireless and wired subnets be
the same – something that is often not the case. In summary, the assumption that the marked
packets make it to the rogue access point such that they can be detected on the wireless
medium is significant and has important implications on the network topology. The second
incorrect assumption that is made by this technique is that the rogue access point will actually
transmit the marked packets onto the wireless medium. In other words, just because the probe
and rogue access point are able to communicate over an Ethernet protocol does not mean that
the attacker cannot configure the rogue access point to not transmit those marked frames onto
the wireless medium. Furthermore, even if the attacker did not want to block all of these
packets from being transmitted onto the wireless medium, the attacker could mangle the
9
packets and therefore eliminate the “mark” that is used for detection (for example, the attacker
could randomly pad the length of the outgoing frames that are transmitted from the wired
medium to the wireless medium). Lastly, this detection technique makes one treacherous
assumption about the rogue access point that is to be detected: it assumes that the rogue
access point will not attempt to appear like one of the legitimate access points. In other words,
there is nothing that prevents an attacker from monitoring the network, cloning an existing,
legitimate access point, and using that BSSID/SSID/etc. For example, an attacker could devise an
algorithm that listens to the network, finds a legitimate access point, waits for that access point
to become ‘quiet’ (i.e. few clients or data packets), and then start broadcasting with the same
BSSID and SSID as the legitimate access point. This scenario is not detectable using a “marked
packet” even if the probe does determine that the access point exists on the network it should
not trigger an alarm because that access point is authorized to be on the private network.
AirTight’s “marked packet” rogue detection technique while unique, clever, and
patented, makes some underlying assumptions that are easily circumventable by an attacker.
This technique differs from competing solutions in that competing solutions rely on human
validation of access points and error on the side of false-positives rather than false-negatives.
Ultimately, the claimed superior rogue detection technique actually becomes a vulnerability
when coupled with AirTight’s zero-false-positive detection system [16]. The vulnerability can be
seen in that attackers have a mechanism to appear legitimate via the mechanisms described
above exploiting the ambition AirTight’s solution has to not trigger false alarms.
In total, AirTight’s provided solution is a strong one and indeed is comparable to the
other industry leaders; however, like all solutions there are security holes that allow attackers a
10
foothold if found. Furthermore, though AirTight’s solution is unique from the cloud hosted
perspective which provides them with a unique argument to obtain customers; particularly that
customers need not own and manage a private data center with private servers. However, the
AirTight approach to the probes differs from that of this project because they are asset-heavy.
Meaning these probes can run independently of the cloud management service, which implies
something significant about the cost of the probes.
2.4 AirMagnet
Founded in 2001 and acquired by Fluke Networks in 2009, AirMagnet is one of the
longest players in the space and have grown to be one of the industry leaders in the wireless
security monitoring space [18]. The solution AirMagnet provides with respect to wireless
security is called AirMagnet Enterprise. This product is comparable to the AirTight and
AirDefense solutions in many ways. This product claims many of the same features as the above
described products and additionally includes some features not explicitly claimed by others. For
example, the AirMagnet Enterprise has the following significant features [7]:
Full channel visibility (including all 200 extended channels)
Rogue detection and mitigation
RF device/interference classification and RF anomaly detection
Spoofed device detection
Denial of service attack detection
Man-in-the-middle attack detection
Evil twin detection
WPS brute force attack detection
11
802.11n fuzzing attack detection
Threat tracing and attacker suppression
Event forensics
Device classification
AirMagnet has an extensive set of features to help manage and protect customers’ wireless
networks. Interestingly, they have also partnered with Cisco to provide an alternate solution
that involves installing probe software on Cisco access points thus significantly reducing install
cost of the system [19]. The AirMagnet solution, like the other solutions described above, is also
backed by numerous patents and intellectual property; however, this system, also like the ones
described above, makes a number of assumptions that cannot be overcome in some cases
[15,16,17,18,19]. First, this system requires a centralized server that is owned, maintained,
serviced, and housed by the customer. This means that any customer hoping to utilize this
system must have a private data center in which to host the centralized server. This implies a
significant assumption about the customer that would purchase this product. Furthermore, the
probes/sensors are designed to operate independently of the central management server [7].
Again, even if this does add redundancy, it places a significant requirement on the compute
power of the probes/sensors (i.e. they are expensive. On average, each probe costs
approximately two thousand dollars – a typical cost for a commercial access point). This implies
that this solution and the solutions described above target a section of the market that has
significant capital to spend. While this may have been a necessary assumption when these
products were first developed, this omits an enormous potential section of the market and
leaves many who desire and need wireless protection solution-less.
12
2.5 Disruptive Technology.
While the above described state of the art was being developed over the past decade or
more, there have been some other significant developments that are important for the
reasoning behind this project. Few, if any, would debate the dramatic change that technology
has caused over the past decade, but few can capture those dramatic changes as well internet
analyst Mary Meeker [25]. There is arguably no one better at telling the story of how things are
changing and capturing the disrupting technologies that change the world as we know it [25].
Over the past several years, Meeker has identified two disruptive technologies instrumental in
the argument for this project: cloud and mobile. Though now largely well-known, the trends she
illustratively exposed show the amazing adoption of mobile devices and how mobile growth is
changing the world [21,22,23]. Furthermore she demonstrated, at least implicitly, the disruptive
nature of cloud computing [21,22,23]. Indeed, it is no longer the case that to start a new
company one needs large amounts of capital investment, personnel, time, etc. The disruption
that cloud and mobile are driving lowers the barrier of entry in many industries to a shockingly
low level. In other words, what used to take twenty engineers and a million dollars’ worth of
capital for servers now can be done by three engineers in a basement for fifty dollars. These
dramatic changes Meeker illustrated by showing how so many things have been re-imagined
due to the disruption of technology. For example, we used to have desktops and notebooks and
now we primarily have tablets and smartphones (Figure 1). The list is extensive [27]:
Then we used land lines for phone communication, now we use mobile phones dominantly.
Then we gathered news from news casts, newspapers, dedicated reports, etc., now we
gather information and news from social media and trending like twitter that is user
generated and real time.
Then we took notes on paper, now we use tools like Evernote.
13
Then we had dedicated cameras and transferred digital files manually, now we almost all
carry a camera that is connected to everything (camera-phone, Instragr.am).
Then we had scrapbooking, now we have Pinterest.
Then we purchased physical books, now we use tablets, e-readers, and digital books.
Then we bought music in hard-media form (CDs), now we have real time streaming of
everything with Spotify and similar applications.
Then we had physical maps and traffic reports, now we have digital maps and crowd-
sourced real-time traffic information (Figure 1).
14
Figure 1: Re-Imagination of Everything
15
Indeed nearly everything has been re-imagined in light of the disruptive technologies that exist
today.
It is evident that technological disruption is present and enabling. What does this mean
with respect to this project? Technology has enabled the re-imagination of everything from
desktops to maps, news, media, etc., why not re-imagine wireless security [27]? Enabled by
disruptive technology, this project is the re-imagination of wireless security. All the solutions
that are the current state of the art are expensive, require large, powerful probes/sensors, and
require well trained users and management [8,10,13]. This project is the re-imagination – the
solution provided by this project is an order of magnitude cheaper, has small probes/sensors,
large data analytics, and leverages the mobility provided by the cloud. In short, the re-
imagination of the state of the art is encompassed in the solution outlined below.
2.6 Asset-Light Orientation
Following her illustration of the re-imagination of everything, Meeker appended to her
analysis regarding these trends using a different perspective [28]. Interestingly the technological
changes driving the re-imagination of everything are also dictating a change in behavior and
operation [28]. In general, the detected trend is an increasing customer shift towards asset-light
lifestyles and solutions. What is meant by asset-light? Meeker best illustrates asset-light via a
series of antitheses. For example, asset-heavy music meant one paid for ownership, bought
albums/CDs, and played music back through dedicated players, now (asset-light) we have apps
with access to the world’s databases of music like Pandora, Spotify, iTunes (Figure 3). With
respect to video, we used to pay for DVDs/Blue-Rays, store them, and watch them on dedicated
players; in the new asset-light era, we have instant streaming access to video content through
16
services like Netflix or YouTube (Figure 4). In other words, the reorientation towards asset-light
saves space, time, and money. From a business perspective, this implies that there is a shift
away from capital expenditure to operational expenditure; a shift away from ownership towards
subscription and service; and a shift away from technical in-house expertise to outsourced
technical expertise.
17
Figure 2: Asset-Heavy vs Asset-Light
18
Thus, Asset-Light Wireless Security as a Service is not only a re-imagination of the state
of the art, but it leverages and supports the customer shift towards asset-light. Instead of
costing thousands of dollars per probe, this solution has one hundred dollar probes. Instead of
paying for full ownership and therefore management, this solution is subscription based and
service-oriented. Instead of being an enormous capital expenditure, this solution is a small
operational expenditure. Instead of requiring highly trained technical expertise, this solution
provides the technical expertise for you. And instead of being only for the vast and wealthy, this
solution is for everyone.
19
3 Problem
As outlined in the introduction, the insecurities one finds in wireless communication
often provide the mechanism attackers need to exploit victims on a larger scale (e.g. stealing
information or credit cards) [4]. These insecurities create a market for the solutions described in
the state of the art and indeed the solutions described in the state of the art provide significant
amounts of revenue for the companies that own them; however, as was described in the
previous section, there are shortcomings to those solutions. Barring the technical shortcomings
of the state of the art, there are some fundamental assumptive shortcomings that provide the
basis for the problem to be solved. Some of those assumptive shortcomings can be derived from
when the decisions were made for these solutions (i.e. the origins of these solutions are over a
decade old). But all of the assumptive shortcomings provide the basis for this project and the
new solution it provides. Whether the assumptive shortcoming is that of assuming a certain
customer, or a certain capital investment, or a certain level of technical knowledge – the
fundamental problem that this project addresses is finding a way to make the state of the art
possible for all customer segments, all scalabilities, in an asset-light, disruptive-technology-
leveraging solution.
Stated from a market perspective, the state of the art does not address the problem
that large customers are not the only ones who need wireless protection. What about small or
medium businesses? What about small coffee shops that want to protect their customers? What
about all the companies that utilize wireless IP security cameras that cannot afford the state of
the art systems? What about residences that want to protect their wireless just like they would
protect their physical doors and windows? This project addresses those questions by addressing
that market segment.
20
4 Idea
So how does one solve the problem outlined above? In other words, what fundamental
building blocks provide this project with the components necessary to bring the state of the art
to all customer segments, all scalabilities, in an asset-light way? How does this project re-
imagine wireless security? The answer to those questions lies in the disruptive technologies
outlined above: the solutions that make up the state of the art were built without the use of the
disruptive technologies that rest at the fingertips of all developers today. In short, the key idea
underlying Asset-Light Wireless Security as a Service is as follows: the computationally expensive
tasks and all other tasks (as much as possible) are relocated from being done on the probe to
being done in the cloud. This asset-light approach is made possible by the highly scalable cloud
resources that are now available due to cloud disruption. Examples of these highly scalable
cloud resources include Infrastructures as a Service (IaaS) like Amazon’s EC2 and Rackspace, and
Platforms as a Service (PaaS) like Heroku, AppFog, Engine Yard, etc. Reducing the footprint of
the probes has several key implications and advantages. First, the cost of the probe is reduced
by an order of magnitude - where before probes cost two thousand dollars, this project uses a
one hundred dollar probe. Second, by providing a cloud service the assumptions about the
customer’s infrastructure and technical expertise disappear altogether. That is, where before
the only customers that could buy wireless security solutions had powerful private data centers,
deep pockets, and highly trained IT staff, now customers need only have a small amount of
money, little to no technical expertise, and a simple network (at minimum). Furthermore, since
the cloud infrastructure is so highly scalable, the asset-light design allows for targeting a broader
spectrum of the market while being linearly scalable (something that is not attainable in the
state of the art solutions).
21
Even more advantageous, moving to an asset-light infrastructure opens doors to much
that has been previously impossible. For example, now that the data is securely ‘freed’ from a
customer’s private network, data can be analyzed more deeply and stored more easily. Likewise,
since the data is now freed, cross-comparisons can be anonymously made across different
subscribing customers to more effectively identify attack patterns, etc. Indeed, there are
numerous other big-data applications and others yet to be devised now that the big-data for
wireless security will be retrievable; to borrow from IBM, Big Data is the new natural resource
[29].
22
5 Design
The above described idea has taken a realized form using the design outlined in this
section. Expressing the design at a high-level, the state of the art as described above has been
redesigned in a new asset-light form factor that leverages disruptive technologies. Leveraging
the enabling technologies (primarily cloud), the state of the art now addresses all customer
segments and all scalabilities while not falling into the same assumptive pitfalls that have
previously limited commercial solutions. Asset-Light Wireless Security as a Service has three
primary components: probes, a Cloud Management Application, and a Cloud Web Application.
The following figure depicts block-level diagram showing the interactions between these three
major components. Looking at the diagram from a bottom-up perspective, probes are deployed
in a wireless environment to collect data on all the wireless devices and activity. These probes
report their data through a RESTful API to the Cloud Management Application. Since the high-
level design objective for this system is to remain asset-light the probes and the intelligence
included in the probe software is intended to be light and therefore allow for asset-light
deployments. The Cloud Management Application collects the data from all probes for all users
and uses that data to carry out its purposes. The Cloud Web Application is used for all customer
interactions and for all user-access to data. The following subsections outline in detail the design
of these three major components.
23
Figure 3: System Architecture
24
5.1 Cloud Web Application
The Cloud Web Application serves the primary purpose of interacting with users. This
means that the web application is responsible for all user management including sign up, sign in,
password management, session management, user interface displays, user preferences, probe
claiming, protection setup, attack initiation, etc. The Cloud Web Application has the design goal
of being a responsive UI both with respect to immediate user interactions and updating user-
facing interfaces with new data from the user’s probes. Additionally, since the target market for
this solution is broad, the user interface needs to be both easy to use and powerful. That is, the
user interface needs to be able to support users with little technical expertise while still allowing
advanced users the ability to perform advanced and powerful tasks. Furthermore, due to the
disruptive technologies described above, the web application is able to serve users accessing via
mobile. As discussed in the future work section, there are extensions to this solution that
involve writing mobile applications to better serve the mobile market; however, this solution
serves both mobile and desktop friendly interfaces to serve a broader initial market. The user
interface leverages open-sourced user interface libraries to provide a modern look and feel.
5.2 Cloud Management Application
The Cloud Management Application serves three primary purposes. First, the
application serves as the communication endpoint between all probes and the cloud
infrastructure. That is, the probes communicate to this application to report results, receive
configurations, commands, etc. It is for this reason that the Cloud Management Application has
been built separately from the Cloud Web Application allowing for independent scalability, more
consistent performance, and better uptime. Second, this subcomponent performs all the
analysis upon the data pushed up by the probes. Specifically, this application is responsible for
25
detecting security threats and other wireless events utilizing large amounts of data and other
detection techniques outlined in the Implementation section. Third, the application is
responsible for notifying users of any event that may be detected. User notifications occur both
through the user interface (as directed to by the management component) and via an email
notification.
5.3 Probes
The probe component of the system serves an important purpose and has important
design specifications. Each probe, though not limited to small hardware, is designed to run on
miniature computers so-as to remain inexpensive. The probes serve two primary purposes. First,
probes collect and report data to the cloud. Second, probes receive and carry out commands
from the cloud. For the first purpose, probes promiscuously scan all channels and aggregate
data including the access points that exist nearby, clients, security types, receive power, etc. The
probes also perform sampled wireless captures of all the frames transmitted on a given channel
for the period of time that the probe is listening on any given channel. Metadata about the
packets transmitted during an analysis period are also submitted to the Cloud Management
Application. In the event that the cloud infrastructure has some task for this probe to carry out
(e.g. a software update or an attack), the probe stops its data collection and carries out the task
either until the task is complete or the probe is told to stop.
These over-arching design goals for the Asset-Light Wireless Security System provide the basis
for a solution that solves the outlined problem. The details with respect to the design of the
system functionality are discussed in the following subsection.
26
5.4 System Functionality
The design objectives outlined above together form cohesive product designed to be
competitive with the commercial state of the art while remaining asset-light and therefore cost-
effective. That is, this system provides the necessary building blocks to obtain the critical set of
features necessary to be considered a state of the art system. The system design consists of two
primary sets of functionality: offensive and defensive components.
5.5 Defense
The top-level defensive design features are as follows:
Rogue access point detection and mitigation (new access point detection)
Man-in-the-Middle Attack Detection (similar to an Evil Twin attack, but more difficult to
detect)
Denial of service attack detection
Evil twin detection
Device/Vendor classification
Misconfiguration detection
Real time alerting
Wireless performance sampling
As discussed in detail in the implementation below, the design of this system not only serves as
a defensive platform, but an offensive platform.
27
5.6 Offense
The offensive portion of the platform is exposed to the user as an attack suite with the
following three design objectives. First, and primarily, the attack suite is used by customers to
perform counter-attacks and slow attackers. Thus, when a threat is detected, the user of the
system is enabled to perform a counter-attack through use of, for example, a denial of service
attack. In more extreme cases, the user may choose to shutdown wireless activity in the vicinity
altogether until further investigations can be made using a ‘Boom’ Attack. Second, the attack
suite can be used for penetration testing. Particularly when a new wireless network is being
brought online, this system can serve the purpose of ensuring proper detection of attacks,
analyzing mitigations to attacks, etc. Third, and last, exposing the attack suite has design
objective of being disconcerting to users. The reason for this is attempt to expose the
insecurities and limitations of shared wireless mediums. Though the project does not measure a
change in perception, providing an attack suite (especially to less technical uses) provides an
important byproduct of showing users why these types of systems are necessary. Furthermore,
the attack suite serves as a secondary go-to-market strategy to target a segment of customers
that are considered hobbyists in the area. In short, this project recognizes that the primary
source of insecurities in this space, and all security spaces, can be traced back to some human
error – usually human ignorance [30]. With the above design objectives for the attack suite in
mind, the following attacks are implemented and exposed to users of the system:
Denial of Service Attack: Client targeted and access point targeted.
WEP Crack: While WEP encryption is declining, there still exist many legacy access points
that support WEP and many others that default to WEP. The reality is that WEP-encrypted
access points exist and this attack will demonstrate to users the notoriously insecure
28
protocol. This attack will require that clients are connected to an access point and will
generate packets using an ARP replay attack that will trigger many legitimate frames to be
transmitted over the wireless medium. The attack will collect the initialization vectors from
these frames and use them to narrow the key space to crack the WEP key. This is an
effective and well-known attack that is eye-opening to any users who think WEP is secure.
The attack will take approximately four to five minutes to crack the WEP key.
SSID Bomb: this attack is unique to this project and simple in nature. Again the purpose of
this attack is to generate awareness, and it can be effective in surprising users. The attack
takes a target SSID, for example, ‘Odell1234’ and generates many SSIDs that vary only
slightly from the seed SSID. The attack uses a custom algorithm to generate the variations
on the seed SSID using techniques like incrementing numbers changing the capitalization of
characters, transposing near characters, removing characters, etc. The result is amusing in
that when a legitimate user attempts to connect to the target access point, it is hidden in a
list of similar looking fake access points. Of course, this assumes that a victim is actively
looking for a specific SSID. Nonetheless, this attack is meant to be relatively benign while
creating awareness that SSIDs need not be tied to a physical address.
Wide Impact Denial of Service Attack: This attack will target a large set of devices with
various characteristics. Variations include attacking all access points and clients with a
specific SSID, attacking all clients and access points on a specific channel, and attacking all
client devices that have a specific vendor or type (e.g. attacking all Apple devices).
Wireless Shutdown Attack: though this attack is another flavor of a Denial of Service attack,
it deserves a bullet of its own. This attack will attempt to effectively halt all wireless activity
in range by performing a denial of service attack on all clients and access points on all
channels without discrimination. Time permitting, this attack could be useful for any
29
network administrator that would rather halt wireless activity while a threat is mitigated
rather than have clients or the network compromised.
WPA/WPA2 Handshake Acquisition Attack: This attack will perform all the necessary steps
to quickly capture, filter, and upload the four-way key exchange used in the WPA connection
setup phase. This key exchange can be used offline to perform dictionary attacks and
determine the WPA/WPA2 pre-shared key.
30
6 Implementation
Through more than 700 hours of pure development time producing more than 13,000
lines of new code, the above described design has been implemented. As previously discussed,
the system is comprised of three primary components: probes, the Cloud Management
Application, and the Cloud Web Application. The high level implementation details regarding
each of these components are discussed the following subsections with details on the system
functionality following. Users interact with the system by communicating via HTTPS to the Cloud
Web Application. The Cloud Web Application and the Cloud Management Application share a
few high-level resources including a MongoDB hosted database. MongoDB is an open-source,
document-based, NoSQL database [31]. It is currently the leading NoSQL database [32]. The
MongoDB database is used to store all persistent data including users, probe information,
collected data, etc. Also shared between the web and management applications, is a hosted
Redis database. Redis is an open-source, in-memory, key-value store/database often referred to
a data structure server [33]. A cloud-hosted email sending service, SendGrid [34], is also shared
between the web and management cloud applications and is used both for user management
(user creation, password reset, etc.) as well as user notifications (i.e., notifications of detected
threats). Probes, via HTTPS, communicate with the Cloud Management Application via a RESTful
[35] interface. In order to ensure that the probes can communicate with the cloud, the probes
initiate the connection between itself and the cloud and thus will not likely be blocked by any
externally facing firewall of a user’s network. In other words, all communication between the
probes and the cloud is initiated by the probes and will therefore pass through any Network
Address Translation (NAT) or network firewall. To reduce the memory resource load of
maintaining many open socket connections to many probes, the probes emulate a ‘connection’
with the cloud via a periodic poll. That is, probes both post data and request configuration and
31
commands from the management application on a regular interval. These intervals are
configurable via a cloud environment variable but are typically ten seconds for the control
interval and thirty seconds for the data interval. That is, probes will make a request to the cloud
seeking the current configurations and commands every ten seconds and will post up data every
thirty seconds. Discussed in further detail below, the management application communicates
the arrival of new data to the web application via a Redis publication-subscription mechanism.
The Cloud Web Application communicates new data to a user’s browser via a long polling
mechanism that provides a robust and performant real-time user interface. Together, these
mechanisms provide a bi-directional real-time user interface (real time meaning it updates
without user interaction). The following subsections discuss in detail the implementation of
each of the three major components and elaborate on the communication between them.
32
6.1 Cloud Web Application
As discussed in the design, the Cloud Web Application has the primary design objective
of dealing with user interactions. That is, this application is responsible for all user management
tasks (sign up, sign in, session management, password management, notification preferences,
etc.) in addition to displaying data aggregated from the user’s probes. The Cloud Web
Application has been implemented with approximately 8,000 lines of code (excluding all third
party libraries). NodeJS is the server-side language used to serve web requests coupled with an
ExpressJS framework used as a model-view-controller (MVC) framework [36], [37]. In addition to
the Cloud Web Application specific code, approximately 500 lines of code are shared between
the Cloud Web Application and the Cloud Management Application. Additionally, the top-level
server-side languages and frameworks, the client-slide utilizes Google’s AngularJS as the client-
side model-view-controller [38]. AngularJS, serves as incredibly powerful tool for building
responsive user interfaces using bidirectional data binding [39]. View content provided from the
Cloud Web Application to the user’s browser is done via the Jade Templating Engine [40]. Other
client-slide open-source libraries that are utilized in this solution include: Twitter’s Bootstrap
(for a modern, mobile-friendly, user interface), jQuery, Highcharts, and Font-Awesome [41]–
[44]. Since the primary purpose of the Cloud Web Application is user-centric, the following
subsections and figures describe the implementation details of this application as a user might
interact with it. Technical details underlying the user interactions are embedded throughout.
The Cloud Web Application is hosted by and runs on the Heroku Platform as a Service
(PaaS) [45]. Heroku is used as a tool to help developers quickly and easily deploy cloud
applications and simultaneously provides for easier scalability and building blocks. The use of a
PaaS in this case allows for a higher focus on application functionality in lieu of dealing with the
33
technical details of cloud scalability. For the sake of brevity, some minute features and
workflows are omitted from the report; if interested please see Appendix B for the Cloud Web
Application code. Readers of this report, if you would like to witness live demonstration of the
discussed features, please visit the Cloud Web Application at the URL provided in Appendix A.
6.1.1 Marketing Information
Though it may not seem necessary to discuss marketing information with respect to this
project, it is necessary when looking at it from a commercial perspective. One of the differences
between the commercial state of the art and this solution is the target market (i.e. this solution
addresses a broader target market). What this means is that that product needs to be marketed
to a broader audience and through more-automated marketing channels. Thus the top-level
marketing material attempts to address a broad market while not obfuscating the value of the
solution. This marketing material can be viewed as the first page displayed to users who follow
the URL provided in Appendix A.
6.1.2 Sign Up
Users interacting with this system must proceed through a sign up processes to become
a user. As one of the design objectives for this subcomponent is to be simple to use, the first
interaction with the system should be as simple as possible. Thus, the user sign up page consists
of the exact bare minimum information: email address and password. The figure at the bottom
of this subsection illustrates this user interface. When a user navigates to this page and enters in
an email address and password, the following steps are taken. First, all form data is validated on
both the client and server side (this is a theme repeated throughout all user interactions). This
34
means that the user must input a valid email address and a password meeting the minimum
requirements (at this point, minimum password requirements only require a minimum of eight
characters in length – should this solution become a commercial product, stronger password
requirements would be instantiated). Second, a new user is created in the MongoDB users
collection. The user is created with certain default parameters and will be marked as a not-yet-
activated user. When the user is created, a password digest is created to securely store the
user’s password. The digest is a salted hash utilizing the bcrypt algorithm to protect against
rainbow attacks [46]. Third, an activation token is generated randomly that is 48 bytes in length.
Fourth, an email is generated and sent to the provided email address that contains a link
parameterized with the activation token. The email step ensures that users sign up with a valid
email address that they own. A user would then follow the link provided in the email. Following
this link triggers the activation of a user and then redirects them to the sign in page. The
following figure shows the sign up page, the activation email, and the sign in page after a
successful activation of the user that can now fully use the application.
35
Figure 4: Sign Up
36
6.1.3 Password Reset
Again, because this solution is intended to be commercially viable and competitive with
the state the art, many necessary features are implemented to assist users with managing their
accounts. Password reset is one of those features and is used if a user forgets his or her
password or perhaps mistyped their initial password on sign up. The password reset work flow is
quite similar to sign up. If a user chooses to reset their password, they go to the password reset
page (by clicking the password reset link on the sign in page) and enter the email address they
used to sign up. This triggers the following steps to occur: the email address is used to ensure
that a valid user exists; a password reset token is then generated and used to generate a
password reset email. The password reset email is then sent to the email associated with the
user in question. Should a user follow the link in the email that contains this randomly
generated reset token, they will be provided with an interface prompting for a new password.
Upon successful entry and submission of a new valid password, the user is redirected to the sign
in page where they may utilize their new credentials. The following figure shows the password
reset initiation page as well as the page provided to users upon following the reset password
link generated for the reset email.
37
Figure 5: Password Reset
38
6.1.4 Sign In
Also essential the user management process, the sign in page is implemented is an
unobtrusive way. Users are prompted to enter their email address and password. Upon proper
client and server input validation, the following steps take place. The user input is validated on
the client side. This validation is for user convenience only and will notify users with a helpful
pop over message for any errors that can be displayed on the client side. Users input two pieces
of information to the system: email address and password. Additionally, there is a Stay-signed-in
checkbox that users may check or uncheck if they would like to remain signed in for a period of
one week without needing to provide their credentials again. Credentials and stay-sign-in
preference is passed to the server securely via HTTPS. Upon receiving user credentials, a query is
performed to obtain the MongoDB document representing the email with the provided email
address. Assuming that a user exists that is associated with that email address, the server then
generates a password digest using the password provided by the sign in page. This digest is
created in the same way that digests are created during a password set or reset – bcrypt. This
digest is compared to the password digest associated with this user. If a match is found, the user
is authenticated. If the user checked the stay-signed-in checkbox, a remember-me token is
stored as a cookie on the user’s browser that will expire in one week’s time. Otherwise, a
transient session is created that will end when the browser is closed. In future requests, the
remember-me token is used to lookup a user. If a user is found, then a valid remember-me
token is provided allowing for sign-in without the user providing credentials. A middleware
called PassportJs is utilized in this process to assist in authentication and session management as
is discussed below. The following figure depicts the sign in page that is displayed to users.
39
Figure 6: Sign In
40
6.1.5 Session Management
Session management utilizes the PassportJs middleware. When a session is created with
a browser, PassportJs handles all the necessary intermediate steps for the application to
function. Chiefly, PassportJs is an abstraction layer used such that code written in the server-
side application layer already knows what user is making the request. In other words, by the
time the request has reached the application layer, the user has been authenticated and
identified such that application logic can proceed.
6.1.6 Use of PassportJs
As discussed to above, PassportJs [47] middleware is utilized in the application to assist
with three things: authentication, session management, and remember-me authentication.
Though PassportJs is useful from an application standpoint as an abstraction layer, it makes calls
into application logic for users, password checking, etc. Thus, the primary purpose for the user
of PassportJs was to futuristically use it for Single-Sign-On authentication using OpenID and
OAuth. Said differently, in the future, users will be able to sign up and sign in using existing
credentials (i.e. sign up and sign in with Facebook or Google). As of today, this feature is not
implemented but nevertheless utilizing PassportJs early on in the project allows for a much
easier upgrade in the future.
6.1.7 Probe Management
Users perform probe management via the Cloud Web Application. This means that all
configurations and setup for probes is done through the user interface. The primary areas of
probe manage are as follows: claiming and unclaiming probes, change probe names and
41
descriptions, and configuring what access points the probes will protect. The following
subsections discuss these three areas in detail.
6.1.8 Probe Claiming
Claiming a probe is necessary for the system to be useful to a user. The claiming process
will associated the piece of hardware purchased or provided to the user with their online
account. The typical process for a user claiming a probe is as follows: prior to initiating a claim
sequence, the user must create an account on the web service (described above) as well as sign
in to the web service. Once the user obtains a probe (via an Amazon purchase, for example) the
user may claim that probe using the following steps. First, the user enters the probe serial
number into the claim dialog (shown below). This serial number will be printed on the outside of
the probe and is a ten digit number generated when the probe is created. When the serial
number in inputted into the dialog, the claim sequence begins. Second, a user will turn the
probe on while it is connected to a live Ethernet port (i.e. the probe will be able to communicate
to the internet). When the probe turns on it will communicate a special request to the cloud
that will allow this probe to be associated to that user. This process is time limited to a two
minute window from when the user enters the serial number. The reason for this time limitation
is explained later. From a technical perspective, the following takes place during the claim
process. First the serial number is communicated from the user’s browser to the Cloud Web
Application. The Cloud Web Application will perform various checks and then create an entry in
the Redis database that will expire after the two minute time period. The Redis entry contains
information about the user that is initiating the claim as well as the serial number. When the
probe communicates to the Cloud Management Application for the first time, it does so using a
marker that indicates that this is the first request. If the Cloud Management Application receives
42
a request with this marker from a probe it will first check to see if the probe already exists in
MongoDB. If, however, the probe does not yet exist, it will check the shared Redis database for
any transient claim records that match the serial number sent up from this probe. If a claim
record exists, then a claim sequence is underway and the Cloud Management Application
creates a new MongoDB document that represents this probe and associates it to the provided
account and inserts this document into the MongoDB database. When this document is inserted
into the database, the Cloud Web Application then displays the success to the user. The reason
for the time limitation is as follows. The three fundamental approaches for authentication are
something you know, something you are, or something you have [48]. One could claim that
since the user knows the serial number of the probe being claimed, that we could use the first
fundamental outlined above, but the serial numbers may have some discernable pattern. So,
rather than having a complex key that the user must enter in successfully, the claiming process
takes advantage of the ‘something you have’ principle. That is, by time-limiting the claim
process it ensures the system that not only does the user know the serial number, but they have
the probe (i.e. they must have the probe since they turned it on during the time window). The
following images show the sequence of screens that a user would be presented during the
claiming process. The description above and the images below depict the successful claiming
path. For brevity, unsuccessful paths are not covered in this report and users interested in these
cases should review Appendix B. In the case where a user wishes to unclaim a probe, they may
do so from the probe management screen shown below. This action will cause the document
representing the probe to be deleted from MongoDB. It is suspected that the primary reason for
unclaiming probes would be to move a probe from one account to another or one user to
another.
43
Figure 7: Claim Sequence
44
Figure 8: Unclaim
45
6.1.9 Protection Setup
Also categorized as a probe management task is setting up what access point a given
probe will protect. In order for the probes to remain light from a hardware perspective, a probe
can protect one access point at a time. The following setup screen shows how probes are told
what access point they are to protect (if any). This information is communicated to the probe via
the probe’s configuration. Additionally, this screen allows users to select which access points
(BSSIDs) belong to their network. I.e. if a user has many access points, but few probes, they can
specify which access points belong to them such that attacks certain attacks can be detected
(e.g. an Evil Twin attack).
46
Figure 9: Protection Setup
47
6.1.10 Account Settings
Users can change account settings using the Cloud Web Application. Account settings
are accessed via the navigation bar under the Account drop down. Using this menu, a user can
perform typical user management tasks like password changes and changing notification
preferences. The notification preferences exposed to users include turning on and off
notifications for minor security threats, major security threats, performance problems, and
misconfigurations. By default, all are enabled. So, if a user does not want to receive an email
notification every time a minor security threat is detected, then they can disable the minor
security threat option. A minor security threat might include the detection of a new access point
that has not yet been validated by a user. The following figures show the Account Settings pages
that are available to users. In the future, users will also be able to change their subscription
settings including the subscription credit card as well as change summary report settings.
48
Figure 10: User Information
Figure 11: Change Password
Figure 12: Notification Settings
49
6.1.11 Scans
After probes are claimed by a user, they collect data from the surrounding area and
upload that data into the cloud. An important piece of data that probes collect is scan
information about the surrounding area. Essentially, this process involves watching wireless
frames transmitted on all channels to detect access points and clients. Scan information
collected by the probes is displayed in various forms in the user interface. The main interface
displayed to users with this information is the scans interface. As seen below, this interface
shows all the collected information about access points and clients that have been detected
including what encryption algorithms are being used, what channel a device is using, what
access point a client is connected to, etc. This interface is useful not only for getting a visual
representation of the airspace but also for initiating targeted attacks. The following figure shows
the scans interface as well as some expanded views depicting the detailed information that can
be accessed when expanding a particular client or access point entry.
50
Figure 13: Scans Interface
51
6.1.12 Events
The term ‘event’ refers to anything that the system detects that is of note or could be of
note to a user. Examples of events include the detection of an attack, a new access point being
detected, or perhaps a misconfiguration of a device owned by the current user. When an event
is detected by the Cloud Management Application, an event document with information about
the event is created and stored in the MongoDB events collection. The Cloud Web Application
displays events in a number of different ways, with the primary display as the event interface.
Through the event interface, users can view the history of detected events, validate new access
points that have been detected, or delete the events. Additionally, when a new event is
detected by the system, a transient notification will be showed in the lower right hand corner of
the screen (much like an operating system notification). The following figures show the two
primary cases where events are displayed to users. Later in the report, more detail will outline
the types of events that can occur and when they occur.
52
Figure 14: Events Interface
53
6.1.13 Protection Information
One purpose of the Cloud Web Application is to be usable to users of various technical
backgrounds. Thus, one of the goals for the Cloud Web Application is to enable users to educate
themselves about this technical area while they are learning about the product. The protection
information page is an attempt to fulfill that goal. The protection information page is a page
educating users of all the ways the system protects their wireless assets. This information
includes information about what attacks are detected as well as what is considered a
misconfiguration, etc. This informational page can be found under the Protect dropdown
labeled ‘info’.
6.1.14 Attacks
The attacks interface allows users to perform attacks from the provided attack suite.
Additionally, the attacks interface provides users a real time view into ongoing attacks. Specifics
of attacks are discussed in detail in a following section. An example usage of the attacks
interface might be a user performing a targeted denial of service attack on a channel, access
point, etc. to ensure that the protection algorithms in place detect and notify the correct
persons of the attack. The Attack interface is equipped with an advanced real-time search in the
case where the user has many attacks and is looking for a specific set of attacks they have run
previously. This interface also serves as a view for captured information. For example, if a WEP
crack attack is performed and a key obtained the attack results will show this key to the user.
Likewise, if a user performs a WPA key acquisition attack (get handshake), and the attack is
successful, then the capture file contain the key exchange will be downloadable from the attacks
interface. The following figure shows the attack interface with some expanded examples
54
depicting previously executed attacks and their results. This interface is accessible from the
attacks dropdown on the navigation menu.
55
Figure 15: Attacks Interface
56
6.1.15 Attack Information
Similar to the protection information page described above, the attack information page
is designed to educate users of the possible attacks available via the attack suite. The purpose
for this education is twofold: first, it illustrates to the users what the attack library is capable of
(product education), and second, it illustrates the many vulnerabilities they are susceptible to
due to using wireless mediums. Additionally, the attacks information page has quick ‘Try It’ links
that will redirect to the attacks page and prepopulate new attack fields as a shortcut to users
exploring the system. This interface is viewable from the attacks dropdown on the navigation
menu. Due to size, a figure is not provided in the report.
6.1.16 Dashboard
Due to the amount of data sent up by the probes, creating a user interface to view
summaries of that data is necessary to make the product viable from a commercial perspective.
The dashboard interface attempts to meet this requirement by providing summary information
about the data sent up by the probes. The dashboard has two primary views, a summary view
and a condensed view. The summary view is intended to be a visual representation of the data
both from demographic perspective and from a performance perspective. From a demographic
standpoint, the dashboard shows summary information about what channels are most utilized
by access points, what security types are most utilized, how many clients are connected to each
access point, etc. From a performance standpoint, the dashboard shows users which channels
are experiencing the highest rates of data transfer and which channels are experiencing the
highest wireless retry rates. The data packets per second, retries, and access points per channel
give solid indicators of performance of a channel and a simple, yet powerful, visual
representation of the airspace. The second primary view is a condensed view of the data. This
57
view attempts to condense the data from three different screens into a single interface. This
view condenses all the scans information, attack information, and events information. Using this
view, advanced users can easily view all the data in a single view. The following figures show
both the summary and condensed interfaces utilized to create a dashboard. This interface is the
first interface shown to users at a top level after sign in and accessible from the navigation
menu.
58
Figure 16: Dashboard Summary Interface
59
Figure 17: Dashboard Condensed Interface
60
6.1.17 Sign Out
Also accessible from the navigation menu, users may sign out of the application. A sign
out action will perform several steps including clearing remember tokens, session information,
and creating new remember tokens. These actions are preformed both on server stores as well
as the browser.
6.1.18 Responsive User Interface
Crucial to the goals of the system, the Cloud Web Application is intended to be a
responsive user interface. Since a primary use case for the system is to be a monitoring tool,
user interface responsiveness is necessary from and end-user requirement. A responsive user
interface is obtained through a number of different strategies. The primary strategy to create a
responsive interface is to utilize asynchronous (AJAX) calls whenever possible and therefore
reduce page load time. In other words, rather than collecting all the data during the initial page
request, the page will load quickly and trigger AJAX background calls to gather the necessary
data to fully load the page. For example, when loading the scans page (or any of the pages) a
user will very quickly be shown a shell page with loading spinners. Meanwhile, AJAX call(s) have
been initiated to the server requesting data. Upon response from the server, the page is fully
populated with data. This is made possible via two primary mechanisms: a long-polling
mechanism coupled with the AngularJs bi-direction data binding [39]. That is, when data is
loaded into the client-side model, AngularJs will efficiently update all portions of the user
interface impacted by the change in data. The long polling strategy works as follows. After each
load of data an AJAX call will be initiated to the server. This AJAX call will remain open for up to
twenty seconds. During this period of time, if new data is collected on the Cloud Management
Application, the Cloud Web Application will be informed of the new data via a Redis publish-
61
subscription mechanism [49]. Upon receiving data on the Redis subscription for new data
related to the page from which the AJAX call was made, the Cloud Web Application will gather
the new data from MongoDB and return that data via the AJAX call. The client-side JavaScript
will then update all objects in the data model that have new data or create new objects in the
case where the data did not yet have an existing object. In the case where no new data was
uploaded pertaining to this page in the long poll interval, the cloud will respond to the AJAX
request so as to prevent timeouts. In the client JavaScript, every time an AJAX request is
completed (either with data or without) a new AJAX request is initiated to the Cloud Web
Application. Using this mechanism, new data pushed from a probe will propagate to the Cloud
Management Application which notifies the Cloud Web Application which sends data to the
browser all with minimal delay. In development, the average time between a probe pushing
data to the cloud and it propagating to the browser is less than 500 milliseconds. Though this
propagation time is impacted by network times, server delays, and client/browser delays, it is
expected that the propagation time will remain below one second on average allowing for a
responsive user interface. Users of the application will be able to experience the real-time-
nature of the interface by watching interfaces being updated immediately with new probe data.
6.1.19 Mobile-Friendly User Interface
As illustrated in the Background section about the disruptions enabling this system to be
created, it is clear that mobile consumption of data is not only significant, but growing. Though
this system is initially focused on providing an interface via the web, it does not neglect mobile
users. In fact, every screen designed to be used by customers is viewable and usable from both a
desktop screen and a mobile screen. To demonstrate the mobile-friendly interface, anyone
using the cloud application via a browser can resize their window to a small screen. As can be
62
seen, there are thresholds in place that transition the data to be viewable on a mobile screen.
The following figure demonstrates the transition by showing the same screen with different
viewport sizes. In the future, creating dedicated mobile applications for major platforms may be
a next step if customer demand provides reasoning for investing in the development effort.
63
Figure 18: Example Desktop View of the Scans Interface
Figure 19: Example Mobile View of the Scans Interface
64
6.2 Cloud Management Application
The second primary system element is the Cloud Management Application. Congruent
with its design, the Cloud Management Application is oriented towards three primary purposes:
probe communication, data analytics, and user notification and alerting. The Cloud
Management Application is implemented in approximately 2,000 lines of code. Similar to the
Cloud Web Application, the Cloud Management Application utilizes NodeJS as the server-side
language coupled with the ExpressJS model-view-controller framework. As mentioned above,
The Cloud Management Application shares approximately 500 lines of code with the Cloud Web
Application. This shared code consists primarily of the model definitions for MongoDB. Sharing a
repository between the two applications ensures that the models are always identical. From a
high-level view, interactions with the Cloud Management Application are as follows: when
probes are turned on the probes begin requesting configuration from the Cloud Management
Application. Alongside these requests are submissions of data collected from the probe’s
environment. Whenever a user changes the configuration of a probe via the user interface, this
is communicated to the probe in its configuration. Whenever data is uploaded by a probe, the
application analyzes that data alongside other data from the same timeframe from that probe
and other probes owned by that user. If attacks are detected based on the data being analyzed
(algorithms discussed below in System Functionality), the Cloud Web Application is notified via a
subscription on a Redis channel; and, if users are configured to receive event notifications, an
email is generated and sent to the user. This pattern is described in individual detail in the
following subsections.
The Cloud Management Application also runs in the Heroku PaaS environment. This
environment allows for simple deployment and easier scalability in that the platform can quickly
add more server virtual machines to handle additional load.
65
6.2.1 Probe Interaction and Data Collection
Communication between the Cloud Management Application and the probes happen
through three routes. The three routes used are /connect, /scan, and /attack. The /connect
route is the route probes poll on a regular interval. The probes poll this route by posting JSON
with self-identifying information to /connect. In turn, the application will respond with
configuration for the probe. Examples of the JSON posted up along with some JSON response
examples are as follows:
# Example JSON Posted from a Probe: { "wifiMac": "00:c0:ca:59:80:e4", "serialNumber": "100000005", "version": "1.0.89", "wiredMac": "b8:27:eb:1e:b6:fc", "guid": "44d7092b-8d6d-4b03-9f72-1a3c9866d528", "ipAddress": "192.168.0.48" } # Example Cloud JSON Response: { "intervalSeconds": 5, "protect": { "__v": 0, "_id": "532a5320090d720200ecf706", "bssid": "F8:1A:67:5A:65:8B", "channel": 6, "encryption": "WPA2", "firstSeen": "2014-03-20T02:31:47.143Z", "lastSeen": "2014-03-20T03:12:20.366Z", "ownedBy": true, "power": -17, "ssid": "Surveillance", "unitId": "532a5309090d720200ecf700", "unitName": "Probe - 100000005", "updatedAt": "2014-03-20T03:14:56.676Z", "userId": "52eadc5be3024e020039eb67", "validated": false, "vendor": "Tp-LinkT", "wps": false, "deauthCountSample": [],
66
"beaconCountSample": [], "txPowerSample": [] } } #Example Cloud JSON Response with an Attack: { "intervalSeconds": 5, "attack": { "data": { "target": { "__v": 0, "_id": "52eaea27118ecd020023a80b", "bssid": "A8:39:44:5C:2A:38", "channel": 1, "encryption": "WPA2", "firstSeen": "2014-01-31T00:10:59.694Z", "lastSeen": "2014-03-20T03:12:20.365Z", "ownedBy": false, "power": -74, "ssid": "Odell", "unitId": "532a5309090d720200ecf700", "unitName": "Probe - 100000005", "updatedAt": "2014-03-20T03:15:43.376Z", "userId": "52eadc5be3024e020039eb67", "validated": true, "vendor": "Actionte", "wps": false, "deauthCountSample": [], "beaconCountSample": [], "txPowerSample": [] } }, "status": "Starting", "type": "BSSID", "unitName": "Probe - 100000005", "unitId": "532a5309090d720200ecf700", "userId": "52eadc5be3024e020039eb67", "updatedAt": "2014-03-20T03:16:02.198Z", "createdAt": "2014-03-20T03:16:02.198Z", "_id": "532a5d727412050200a59270", "__v": 0 } }
As can be seen from the configuration, the application may respond with instructions
about which access point to protect. Or, the cloud may respond with an attack that has been
67
triggered by a user. Lastly, the /attack route is used for probes posting attack results. For
example, if a probe performs a WPA handshake gather attack, the resulting information
(including packet capture file) will be posted to /attack. Communication between probes and
the Cloud Management Application can be performed over HTTP or HTTPS. HTTP protocol is
often used for ease of development, but all data communication between production probes
and the Cloud Management Application will be protected by the HTTPS protocol. Further details
concerning probe to Cloud Management Application can be learned from the Appendices below.
6.2.2 Automated Probe Updates
Essential to the success of the service, the system provides automated and fast updates
to all probes connected to the system. The probe update process works as follows: triggered by
adding some new probe feature, fixing a bug, or adding code that detects new threats, a probe
release is created. This release automatically gathers all script files and other code pertaining to
the probe and creates a package. This package is the uploaded to a cloud file service (Amazon’s
S3 Storage). After the package is uploaded, the release software notifies the Cloud Management
Application of the new probe update. After this release process has been completed, the next
time any probe communicates with the Cloud Management Application with a software version
less than the latest update, the application will respond with an update command containing all
the necessary information for the probe to update itself. After the probe updates itself
(discussed below in the Probe subsection), the probe will communicate again to the Cloud
Management Application using the /connect route. In the new post of demographic information
(assuming the update was successful), the probe will report a new firmware version and
data/configuration flow continues as usual. Furthermore, the update process can be enhanced
using a Content Distribution Network (CDN). That is, the package created by the automated
68
release process will be uploaded to Amazon’s S3 which then propagates faster downloads via
Amazon’s CloudFront CDN [50]. This update process was intentionally developed as an initial
feature of the system and utilized in development of the probes and Cloud Management
Application to ensure the process was robust. All software updates for the probe, Cloud Web
Application, and Cloud Management Application, occur without user interaction to ensure that
critical updates propagate quickly and ensure that less-technical users of the system are not
hindered by cumbersome update processes.
6.2.3 Event Detection
The Cloud Management Application, as discussed in the Design, is responsible for the
analysis of data reported by all probes owned by a user to detect security problems, access
point misconfigurations, performance problems, etc. called Events. An Event represents
something of potential note to a user of the system that occurred in a point in time. When a
new event is detected and that event has not been detected recently triggered by the probe
reporting data, then a new document is created representing the event and that document is
inserted into MongoDB. After the insert is complete, a publish is performed on a Redis channel
that is used to trigger any real-time user interface updates for the Cloud Web Application. The
System Functionality section discusses in detail the types of events that can be detected as well
as the algorithms utilized to detect said events.
6.2.4 User Notification
Also a Cloud Management Application responsibility is user notification. When a new
event is detected, and the user preferences indicate that this user would like to receive a
69
notification per this class of events, then an email is generated containing event information and
that email is sent to the user. Similarly, when an event is detected a transient notification
document is created and inserted into MongoDB. This collection of temporary notifications is
used in the Cloud Web Application to display a running set of notifications to the user. Seen in
figures above, any user using the Cloud Web Application will see a real-time notification pop up
in their screen.
6.3 Probe
The third and final system component completing the system implementation is the
probe. The probe software is implemented with 3000 lines of new code written entirely in
Python. The Python code utilizes lower level system tools (i.e. tools like tcpdump) for tasks
considered performance sensitive. So, for example, when performing packet captures, the
probe python code utilizes an underlying tcpdump process to promiscuously capture wireless
traffic. The probe implementation closely follows the designed purposes for the probe. That is,
the probe attempts to be as light as possible so as to be able to run on limited-resource mini-
computers. The probe software runs in a demonized state consisting of several threads each of
which that spawn sub processes for various underlying tasks.
The top level daemonized process that runs in an event loop will spawn a scanning
thread that is used for data collection. In normal operation, the top level process will loop and
sleep on a cloud-configurable interval and in that loop pull down its configuration from the
cloud. Meanwhile the scan or data collection thread captures traffic and scans the 802.11
channels for data and reports that data to the cloud on a separate interval. Details regarding the
subcomponents of the probe are outlined in detail in the following subsections.
70
The probe software is designed to be cross-platform and compatible with any suitable
Linux-based system. However, in order to provide customers with a known standardized piece
of hardware, the probe software was developed on and will be released using the Raspberry Pi
miniature computer [51]. This variation of probe consists of the Raspberry Pi coupled with a USB
wireless card capable of high-power wireless transmission and a significant antenna gain for
significant reception range. Technical specifications about the Raspberry Pi can be found here
[51]. Technical specifications regarding the USB wireless card can be found here [52]. Again, this
is only one possible variation of probes and any other suitable system could be used (including a
laptop, a wireless access point running Open WRT [53], a Beagle Bone [54], etc.
6.3.1 Setup
In order for the probe to be successful in its data collection and attacking purposes,
there are a number of setup procedures that must happen before the probe software can
interact with lower level interfaces for wireless frame reception and transmission. This setup
process consists of several steps including initiating a monitor network interfaces through which
wireless frames can be transmitted and received. In the Linux operating system, this implies that
the underlying drivers that interface with the wireless card being used support these actions.
Furthermore, the probe software setup creates a custom country code with open wireless
regulations (i.e. full 2000mW transmit power allowed, and all 14 802.11 2.4 GHz channels open).
This custom country code allows the probe to transmit and receive on channels and with power
that may be restricted in some countries. Thus, if commercialized, this customization would
need to be tailored to the country in which the probe operates – specifically, when transmitting
wireless frames (rather than just receiving), future probe versions will need to take into account
government regulations in order to become a fully commercialized product. Lastly, the probe
71
setup consists of setting all logging channels and directories such that the probe software can
operate as a pure Linux service and follow all of the best practices for Linux services.
6.3.2 Data Collection and Submission.
Paramount to the probe’s purpose is data collection and submission to the cloud. The
data collection process happens in a separate thread to ensure that the data collection and
submission does not interfere with the probe control/configuration interface. The data
collection thread collects data by scanning through all of the 2.4GHz 802.11 channels collecting
packets and tracking devices. Access points and clients are discovered using typical processes
using the analysis of frames. This data is collected into local in-memory data structures.
Simultaneous with the data collection of scan results, the probe performs a continuous packet
capture for the data collection interval. In other words, before the data collection process starts
channel hopping and collecting data, it also has started a continuous packet capture that will be
stored to disk and analyzed at the end of the interval. This packet capture is used to perform a
deeper level of protection via packet inspection and baseline analysis that is discussed in detail
below. At the completion of a data collection interval, the data for that interval is processed and
posted up to the Cloud Management Application. Though data is posted to the cloud, collection
of data continues independently and uninterrupted on a separate processes.
6.3.3 Cloud Command Response
As discussed in the Design, the probe is intended to be Cloud-dependent. This
dependency ensures that the probe remains asset-light. To achieve this purpose, probes trigger
their behavior off of cloud commands. So, the top-level thread for the probe has the sole
72
purpose of the polling the cloud for configurations and commands. When instructions are
received from the Cloud Management Application, the top level thread starts and stops sub-
threads as necessary to perform the received command. So, for example, when a probe is told
to perform an attack, it first stops the data collection thread and then starts an attack thread.
The started attack thread would then run until either the attack was completed or a cloud
command was received halting the attack.
6.3.4 Daemonization
The probe software is designed to be a best-practice-following Linux service for several
reasons. Some reasons for this implementation include cross-platform compatibility (probes
could run on a laptop or access point in the background), startup initialization and scheduling
(the service can be started on startup and restarted if it crashes), etc. Achieving the goal of
being a Linux service is done though demonization (becoming a background process). The probe
software achieves this using the standard double-process-fork method that contextually
detaches [55]. As a byproduct of becoming a service, the probe software implements
standardized logging (much like system logging) since the background process can no longer
write to the standard output devices (stdout, stderr).
6.3.5 Attacks
In the case where a user desires to utilize a probe for an attack rather than for the
typical purpose of protection, an attack is initiated via the user interface. This user action
propagates to the probe via the probe’s configuration. When the probe receives a command to
perform a particular attack, it will halt the normal data collection thread and initiate an attack.
73
The attack thread that is started will perform a number of various actions depending on the type
of attack requested. In most cases, the attack thread spawns a sub process to perform
performance-sensitive actions. In some cases (e.g. WEP Cracking), the attack thread will spawn
several sub processes all performing different tasks (e.g. one process gathering initialization
vectors while another process calculates possible keys and a third process is artificiality
stimulating the target to generate more traffic). Throughout the duration of any given attack as
well as upon completion of any attack, the attack thread reports results to the Cloud
Management Application via the /attacks route. The data contained in these communications
varies depending on the type of attack.
The specific functionality and algorithms pertaining to each available attack are
discussed in detail in the System Functionality section below, but those attack algorithms share
the pattern described in this subsection.
6.3.6 Protection
When probes are instructed to ‘protect’ a certain access point that is owned by the user,
a probe will augment the information gathered and supplied to the cloud. In addition to all the
scan data and top level information send to the cloud, the probe will analyze a sampled set of
frames transmitted and received by the designated access point. In performing this additional
data collection, the system can create a baseline representing the access point owned by the
current user. Additional information that is collected, for example, includes the frames
transmitted by the access point being protected. This means that some characteristic
information is reported to the cloud representing every detected wireless frame transmitted by
the access point. That is, for every frame the access point transmits, the probe will report what
74
channel that frame was transmitted, the receive power (at the probe) for the frame, the type
and subtype of the frame, and the received timestamp. As described in the System Functionality
section below, this information is used to detect certain attacks like Denial of Service Attacks
and Man-in-the-Middle Attacks. The following JSON is an example of the data that might be
reported to the cloud from a probe after a certain data collection interval that will be used along
with historical data to detect threats:
{"power":[-17,-17,-17,-17,-15,-21,-17,-17,-17,-17,-17,-15,-
17],"subtype":[8,8,8,8,8,8,8,8,8,8,8,8,8],"type":[0,0,0,0,0,0,0,0,0,0,0
,0,0],"ts":[1395286187.362139,1395286187.464499,1395286187.566815,13952
86191.867175,1395286192.07183,1395286195.14008,1395286196.368162,139528
6196.470898,1395286196.573325,1395286200.975138,1395286201.077541,13952
86205.476546,1395286205.578874],"channel":[6,6,6,6,6,6,6,6,6,6,6,6,6]}
6.3.7 Vendor Lookup
In this age of disruptive technology, one of the phenomenon’s seen by network owners
is a sever increase in wireless devices. That is, now that nearly everyone has a device that could
potentially also act as access point in their pocket (their smartphone), it is increasingly difficult
to determine if the device is benign or if it is a threat. One of the features that assist network
owners in protecting their networks is device classification [16]. This means that instead of a
MAC address being displayed, a user of a device classifying system may also be shown what type
of device was detected. This system attempts to provide a similar functionality via vendor
identification. In other words, for every access point and client detected, the probe will attach
the registered vendor that owns that MAC address. This is useful not only from a demographic
75
information standpoint, but also from a threat analysis standpoint. When a new device is
detected, the probe will perform a binary search using the first three bytes of the MAC as a key
to find the vendor name associated with that MAC address. Since MAC addresses can be
changed by any attacker, this method cannot be used to detect threats, but can be used to
augment confidence and provide better system usability.
6.3.8 Data Usage and Memory Usage
Since the probe is designed to be asset-light, certain mechanisms are in place to ensure
that limited resources are not consumed without check. For the first release of the probe, both
memory consumption and local storage consumption are limited using a recycling mechanism.
Simply put, recycling of memory usage and disc usage are done through period restarting of
processes and even the probe as a whole on a periodic basis. In other words, as a consequence
of operating system paradigms and the significant amount of data that flows through the probes
coupled with the always-monitoring use case for the probe resources are released by
periodically restarting the probe service and thus releasing memory and cleaning up storage
utilization. Additionally, due to operating system decay and use of limited resources, the probe
is made robust via recycling the entire operating system on a long interval. This recycle period
can be randomized and its duration is less than that of any significant attack; thus, it does not
pose a significant limitation to system. This approach allows for an asset-light probe and is made
possible by the data being stored in the cloud with only transient local copies.
76
6.3.9 Probe Update
As discussed above, there exists a mechanism to quickly and automatically deploy new
software to the probes operating anywhere in the world. The process for how this is triggered in
the cloud is discussed above which then causes the command to be issued to all probes behind
in software version to perform an update. This command instructs the probes to perform the
following steps. First, the probe service will halt all current threads and processes. After only the
top-level thread remains for the service, the probe service initiates a separate process with the
update information and then halts itself. With the probe service stopped, the update process
can begin as follows. First, the update package is downloaded via the URL provided in the
update command. Second, upon successful completion of the download, the update process will
delete the current probe code and extract the new update in to the probe location. In some
cases, the update may consist of performing other system updates that will also be performed.
Upon successful extraction the probe service is restarted and normal flow continues.
Additionally, since the code for the update processes lives entirely in memory at the point of
extraction, the extraction of the new update also overwrites the update script allowing for
changes in the update process in the future. The update script is failure redundant and will
restart the probe (thus triggering a retry) upon any type of error. This process was and is used
for probe development to ensure robustness of the process.
6.4 System Functionality
The above subsections discussing the system implementation intend to provide a
description of the system from a component standpoint. The following subsections attempt to
discuss the system from the standpoint of functionality including the types of attacks, methods
and algorithms for protection, etc. From a system functionality standpoint, the system has two
77
primary modes of use: offensive and defensive. The offensive mode of use is primarily
represented by the attack suite provided to the users of the system. The offensive mode is
designed and considered to have ad-hoc usage for a number of reasons including penetration
testing, systematic auditing, counter-attacking, vulnerability education, etc. The primary mode
of operation for the system is the defensive mode. This mode is a continuously running, base-
lining, alerting, mode of operation. These two primary modes are discussed in detail starting
with the offensive mode and discussions follow a per-feature (per-attack, per-protection-type)
flow.
6.4.1 Attack Suite and Offensive Functionality
The attacks provided by the attack suite, as it is implemented today, are as follows:
Denial of Service (client-targeted, vendor-targeted, channel-targeted, access point or
network-targeted, and targeting every device)
SSID Bomb
WEP Crack
WPA Key Handshake Acquisition
Other attacks that may be implemented at a later time if customer demand implies a desire and
are discussed in the future work section including cloud-augmented dictionary attack and an
automated man in the middle attack.
78
6.4.2 Denial of Service Attack
One of the easiest and most prevalent forms of wireless attacks found in the wild today
is a denial of service attack. A denial of service attack in the wireless space is similar to any other
space in that the attacks goal and or purpose is to prevent clients from accessing some resource
– in this case wireless access to the network. The following figure [56] is the state diagram for
clients associating to a wireless network. In this diagram, clients must traverse from State 1:
Unauthenticated Unassociated to the final state before the flow of data frames can commence.
This traversal is done by first authenticating with an access point and then associating to that
access point. However, the important state transition on this diagram is the transition from
State 3 to State 1 a deauthentication transition. This transition happens when the access point
deauthenticates a client via a deauthentication 802.11 management frame. That is, when a
client receives a deauthentication frame from the access point to which it is associated then it
will regress to Stage 1 and restart the authentication and association process.
79
Figure 20: Association State Diagram
80
This diagram illustrates what happens during a deauthentication attack. Likely the most
important vulnerability and weakness of typical wireless communication mediums is twofold.
First, management and control frames that traverse the medium are in clear text. In fact, the
802.11 header information transmitted from one endpoint to another is in clear text. Second,
frames sent from any given endpoint are not mutually validated. Meaning there is absolutely no
guarantee that the source MAC address in the 802.11 frame is actually the endpoint that sent
the frame. This means there is nothing preventing any endpoint from transmitting
deauthentication packets posing as a different endpoint. Hence, this vulnerability makes denial
of service attacks possible and simple.
To perform a denial of service attack, all the attacker must do is formulate a frame
deauthenticating a client, or clients, that will appear to be sent by the access point to which
these client(s) are associated. When this fake deauthentication frame is received by the client, it
moves to State 1 of the diagram above and attempts to reconnect. Some clients will even
artificially insert some delay before attempting to re-connect but re-connecting often takes
hundreds of milliseconds at minimum and often seconds for most operating systems. Thus to
continuously deny access to a particular network, the attacker only needs to continuously send
deauthentication frames to the targets. The denial of service attack provided by this system’s
attack suite utilizes this described method.
Deauthentication frames can be sent in two forms: broadcast and unicast. A broadcast
deauthentication attempts to deauthenticate all clients associated with some access point by
sending the frame to the broadcast address (FF:FF:FF:FF:FF:FF). While this may seem like the
most efficient way to deauthenticate clients, some clients are implemented to ignore
deauthentication frames that are broadcast frames to assist in protecting against denial of
service attacks. The second form of deauthentication is a unicast deauthentication. The unicast
81
form sends a deauthentication frame directly at a specific client. That is, a fake frame is
formulated from the target access point with the destination of a specific target client. The
unicast form of deauthentication is a stronger form of attack and ensures that any client
targeted will reset to State 1 in the state diagram shown above. The denial-of-service-attacks
provided by this system utilize both of these forms simultaneously or individually depending on
the type of attack.
6.4.3 Client, Access Point, or Network-Targeted Denial of Service
The simplest and most common flavor of a wireless denial of service attack targets a
specific access point or client. The simplest form being a client-based attack. In a client based
attack, the attacker will formulate a deauthentication frame directed at the target client with a
source address of the access point to which the client is associated. The attacker then sends the
frame or bursts of the frame on a regular interval throughout the duration of the attack. In a
client-based denial of service attack, only a single client is impacted.
Similarly, in an access point based attack, the attacker formulates several
deauthentication frames for all clients connected to the target access point as well as a
deauthentication frame directed at the broadcast address. These frames are transmitted in
bursts or individually on a regular interval during the attack and will impact all clients associated
to the target access point. This attack effectively halts all data traffic to and from a particular
access point.
Lastly, a network-based (SSID) attack will target all access points (and therefore all
clients) with the same SSID. For example, if a corporation has many access points all serving the
network named “ACME Wireless”. This attack will formulate deauthentication frames for all
clients connected to any access point broadcasting that SSID as well as deauthentication frames
82
to the broadcast address sourced from any access point broadcasting the target SSID. In this
case, since the access points may be on different channels, the probe will cycle through all
channels, on which an access point resides that broadcasts the target SSID, and send the
appropriate burst of deauthentication frames for that channel. This form of attack can render a
wireless network inert for any portion of it inside the probe’s range.
6.4.4 Vendor Targeted Denial of Service
Unique to this attack suite, there are other forms of denial of service attacks that target
victims in unique ways. This attack targets clients based on their vendor or manufacturer. This
means that a denial of service attack can be made to all devices of a certain type or sold by a
certain company. To illustrate this attack, the system provides an attack called the Poisoned
Apple which targets all devices manufactured by Apple. This attack is useful particularly when
demonstrating to a group that has different types of devices. For example, if two devices are
place side by side (an iPhone and a Samsung phone for example) and both are associated with
the same access point, the Poisoned Apple attack will block the iPhone from connecting to the
access point while allowing the Samsung phone to pass through. This attack is done using
following technique: for every client that has been discovered by the probe, that client’s mac
address is used to determine the vendor origin for the device. If the vendor is the target vendor,
for the example attack described above if the vendor is Apple, then that client is added to the
list of targets. The probe then creates targeted deauthentication frames for every client in the
target list sourced from the access point to which each client is associated. The probe then
bursts the targeted deauthentication frames on appropriate channels repeatedly while cycling
through the pertinent channels.
83
6.4.5 Channel Denial of Service Attack
In some cases, users of the attack suite may which to halt all traffic on a particular
802.11 channel. In this case, they would use a channel based attack that creates
deauthentication frames for all clients and to the broadcast address from all access points on a
particular channel. The probe then halts traffic on that channel by transmitting these pre-
allocated frames repeatedly effectively shutting down all traffic on that channel.
6.4.6 ‘Boom’ Denial of Service Attack
In other cases it may be desirable to halt all traffic for all clients, networks, access
points, and channels altogether. This might be educational in nature, but could also be seen as
necessary to halt some ongoing attack with broad-stroke approach. The attack suite provided by
the system that performs this global denial of service attack is called the Boom Attack. In this
attack, deauthentication frames are generated for all clients connected to any access point on
any channel, network, etc. The probe then transmits these frames on the appropriate channels
repeatedly while cycling through all 802.11 channels. This attack effectively is a protocol-level
jamming attack for the 802.11 spectrum. This attack is indeed effective for any device in range
of the attacking probe. Though the probe must cycle through all the channels, it does so fast
enough that any client does not have enough time to re-associate to its access point (see state
diagram above). Thus by the time a client is attempting to re-associate to an access point,
another deauthentication is received and the process repeats itself. Experimentally, the probe is
capable of cycling through all the channels transmitting deauthentication frames in a typical
environment in about a half of a second.
84
6.4.7 SSID Bomb
Though not particularly malicious in nature, this solution provides an attack called an
SSID Bomb. Again, this attack’s purpose is primarily educational and emphasizes the above
described underlying problem that anyone can formulate any management or control frame and
transmit that frame into the wireless medium. The SSID Bomb attack illustrates this principle by
creating many 802.11 beacon frames and transmitting those frames into the wireless space. The
SSID Bomb attack works as follows: a user selects a seed or source SSID. Then the system
creates many minor variations on that seed SSID to generate a large list of SSID’s that are
visually very similar to the initial SSID. The probe will then generate beacon frames representing
each SSID and transmit these beacon frames as if it was an actual access point. The result is that,
to anyone looking for beacon frames, many similar-looking SSIDs all appear as real access points.
For example if the source SSID was ‘Surveillance’, the resulting list of SSID’s that would be
algorithmically generated would be as follows:
Surevillance, Surveillance5, Surveillances, Surveilllance, Surveillnace, SurvEillance, SurVeillance, Surveillance1, Surviellance, uSrveillance, Suurveillance, Surrveillance, Surveillanec, Surveillance0, Survillance, SurveillAnce, SurveilLance, SurveillanCe, Surveillance2, Survveillance, Surveillnce, Surveillane, SurveillaNce, Suvreillance, Surveillance, Surveillacne, Survellance, Sureillance, SurveIllance, Surveillance8, Surveilance, urveillance, SUrveillance, Surveillancee, Surveillace, Surveillance6, Suveillance, Surveillance7, Surveillance9, SurveillancE, Sruveillance, surveillance, SSurveillance, SurveiLlance, Survelilance, Srveillance, Surveillannce, Surveillaance, Surveiillance, Surveillancce, Surveillance4, Surveeillance, SuRveillance, Surveillance3, Surveilalnce From a client perspective, the resulting access point list might look something like the following
figure:
85
Figure 21: Example SSID Bomb
86
Again, this does nothing to clients who have the SSID information for their access point
cached in the client system; however, this mechanism is useful in illustrating the underlying
principles and is fun to demonstrate.
6.4.8 WEP Crack
The Wired Equivalency Privacy Standard was released in 1999 [57]. WEP has had a long
relationship with insecurities over the years, but despite those insecurities it still is found in the
in use today. In fact, the use of WEP to secure the wireless network is what led to the Tj Maxx
compromise in 2007 [58]. In August of 2001, Fluhrer, Mantin, and Shamir published a
cryptanalysis of WEP exposing it’s vulnerabilities including a technique that gathered
initialization vectors (IVs) to narrow down the RC4 keyspace and determine the RC4 key [59].
This technique has been perfected in various forms from passively collecting packets with IVs to
stimulating artificial traffic to more quickly crack the RC4 key. The mathematics behind a WEP
RC4 Key crack are known to those interested in the art, but are outside the scope of this report.
Trivially stated, the algorithm captures particular initialization vectors allowing for an increased
probability of determining the stream key. Thus, by capturing initialization vectors, attackers can
determine the key in as little as a few minutes on typical hardware. The attack provided in this
system’s attack suite uses these previously invented algorithms to perform a WEP Crack from a
probe. To carry out this attack, a user need only select an access point that uses WEP and the
probe’s attack will commence. The probe uses an ARP-replay technique that will replay an ARP
packet into the target network and thus generate ARP responses. This process is repeated
rapidly and therefore generates many legitimate frames to be transmitted. These legitimate
frames that are transmitted contain initialization vectors needed to perform the WEP crack. This
attack requires that a client be associated to the target access point. Upon a successful crack of
87
the WEP key, the key is shown to the user via the attacks interface. Experimentally, the probe
and system together perform cracks in roughly three to five minutes consistently.
6.4.9 WPA Handshake Acquisition
The final attack provided in the system’s attack suite is the WPA Handshake Capture or
Acquisition. During the authentication phase for WPA and WPA2 a four way key handshake
occurs two perform several actions including creating a session/transient key for the connection
as well as authenticate via a Nonce. WPA and WPA2 remain the state of the art for pre-shared
key algorithms, but attacks are still possible on these protocols. Again, due to the shared
medium nature of wireless, the attacker can use the four-way key handshake to perform a
dictionary attack on the target access point. Though the details regarding the WPA/WPA2
algorithm extend beyond the scope of this document (see [5]), it can be seen simply via a
simplistic explanation of the four-way key handshake. The handshake performs the following
steps explained here omitting extraneous detail. First, the access point sends a nonce-value to
the client that is authenticating. Second, using this nonce from the server, the client has all the
components to generate the PTK (Pairwise Transient Key). The PKT is generated as a SHA-1 of
the Master Key (what are attempting to determine), the access point nonce, the client nonce,
the access point MAC address, and the client MAC address. In the second frame of the four-way
handshake, the client sends the access point its own nonce alongside information containing
SHA-1 generated hash. At this point, any attacker listening to the exchange has all pieces of
information except for the master key. Thus, attackers can use dictionaries of weak master keys
to perform a dictionary attack. While the system does not yet perform a full dictionary attack, it
does enable users who wish to perform their own dictionary calculations. The WPA Handshake
Acquisition attack works as follows: a user selects a target access point running either WPA or
88
WPA2. This attack is propagated to the probe that will start capturing traffic for that access
point as well as deauthenticating its clients to trigger key handshakes to commence. If a four-
way key handshake is detected, the probe will then take all the frames captured and strip it
down to only the important frames. That is, the probe will generate a capture file containing
only the four-way handshake and a single beacon frame. This capture file is uploaded to the
cloud where it can be downloaded by users and used for either locally run dictionary attacks or
using third party services that provide fast cracking through cloud cluster computing.
6.4.10 Defense and Protection Functionality
The second and primary mode of operation for the system is the protection mode
where probes coupled with the cloud work to protect the user’s wireless assets using the
functionality described in this system. The various components that comprise the defense mode
of the system have been discussed through this report but section is concerned in discussing
how those components function together as a whole to provide an asset-light solution to
wireless security. To reiterate for emphasis items that have been sprinkled throughout the
earlier part of the report, probes collect information about the surrounding airwaves including
the devices in the vicinity and other information including summary information about the
frames transmitted by the access point it is protecting. This information, along with other
probe’s information, is uploaded to the Cloud Management Application for further analysis and
threat detection. The following subsections describe in detail from a feature breakdown how
the system functionality achieves its purpose of protecting a user’s wireless assets.
89
6.4.11 Rogue Access Point Detection (New Access Point Detection)
As one interested in the area of wireless security will quickly find, the detection and
mitigation of rogue access points remains the most difficult and most important problem that
network owners face today. Furthermore, this problem is only growing as more individuals bring
their own devices capable of being a wireless hotspot near the network owner’s airspace. Yet
even though rogue access points are considered one of the highest security risks, the nature of
wireless mediums and the shared airspace make automatic detection of rogue access points
difficult and even impossible. While others claim to have created solutions that will flawlessly
detect rogue access points connected to the user’s network [16], these solutions have clear
problems and make fundamental misassumptions about the attackers adhering to the protocol
rules. So, these solutions actually do more harm than good because it provides attackers a
seamless way to enter the network undetected as users of these solutions have become
complacent that their system will differentiate between benign access points and rogue access
points. The reality of the problem is that there is no solution that can perfectly detect rogue
access points that does not make an assumption about how the attacker might counter. Thus,
this system takes a different, but more robust approach. Instead of attempting to classify newly
detected access points as rogue or neighbors, the system will notify the user of any newly
detected access point that has not yet been validated. In doing this, it removes the burden from
the system and therefore removes the possibility that the system could miss a rogue access
point. This strategy, while perhaps inconvenient, is the only solution guaranteed to notify a user
of a potential rogue access point in every case.
To provide the new access point (and therefore rogue access point) detection, the
system must maintain information about every device and information about whether that
device has been validated by a user. Thus when a new access point is detected, a user is notified
90
of this detection and it is up to the user to know their environment and determine if mitigating
action is necessary. If the access point is located or in some way found to be benign (i.e. a
neighboring facility’s access point) then the user can validate that access point with the system
and future detections of that access point will not create notifications. In future versions of the
service, there may be a classification helper to assist users in making decisions about rogue
access points. For example, if the system is being turned on for the first time, then it is likely that
the access points being detected are benign and being inserted into the system for the first time
whereas if the system has not detected a new access point in a longer period of time, then new
detections will have a higher severity metric for the user’s convenience.
An additional benefit of an asset-light approach to this solution is a tighter coverage of a
user’s airspace area. In other words, where older solutions have large probes that have a
broader range and perhaps detect devices at greater distances, this property also leads to a
greater probability of detecting neighboring access points and creating false alarms. Indeed
minimizing false alarms (or the crying-wolf phenomenon) has significant benefits when
presented to human beings and natural human tendencies to acclimate [30]. In this system,
since probes are smaller and more frequently placed, the coverage over the desired area is
more accurate and there is less bleed-over into unwanted domains, thus leading to less false
alarms and better overall protection.
In summary, a manual validation mechanism for rogue detection, while somewhat
tedious, is the most robust solution and this system provides that solution with high usability to
its users. Furthermore, these detection mechanisms coupled with the attack suite provided to
users allow for quick mitigation while a physical device is located and thus provide an easy
mitigation solution to a difficult problem.
91
6.4.12 Denial of Service Detection
As illustrated by the systems attack suite, there are a number of denial of service attacks
that render the airspace effectively jammed. Due to the shared medium nature of wireless,
protection against denial of service attacks stops at detection. That is, aside from changing the
protocol or physical nature of wireless, no system can prevent a denial of service attack.
Nonetheless detection of this attack can be very useful to owners of a network. The system
described in this report provides detection of denial of service attacks using the following
mechanism: when a probe is instructed to protect a particular access point, that probe begins
gathering data about that access point’s behavior and uploading that data to the cloud. Specific
to detecting denial of service attacks, the data collected by the probe concerns the types of
frames the access point transmits on a sampled interval as well as the receive power of those
frames at the probe. Using a simple fuzzy logic algorithm, a denial of service attack is detected
when an anomaly happens in the number of deauthentication frames being sent by the access
point occurs coincident with a receive power anomaly. Experimentally, this detection algorithm
has been flawless and is simple in that denial of service attacks are obvious from a data
perspective. The fuzzy logic algorithm is used to ensure that the system does not falsely alarm
due to a legitimate deauthentication. By also looking for a pattern change in the receive power,
the system is assured that the anomalous increase in deauthentication frames was not
legitimate but transmitted by a third party device. Anomalies are calculated as a three standard
deviation difference from a running average mean.
While detection of denial of service is the most any system can do, this system does so
immediately and with high accuracy and thus enables users to better protect their wireless
assets.
92
6.4.13 Misconfiguration Detection
While misconfiguration detection may seem insignificant at an initial glance, when one
considers that insecurities can always be traced back to human error [30], providing tools and
mechanisms to minimize the impact of human error has great benefits. This system provides
that mechanism by detecting if assets owned by the user (as specified via the user interface
configuration) are misconfigured or unwisely configured in some capacity. For example, if an
access point that is owned by the user utilizes WEP for the security protocol, then the user will
be immediately notified of this insecurity. Another example use case is the firmware reset of a
piece of hardware. That is, when someone performs a firmware reset on an access point, this
often triggers the access point to clear all security and therefore would be seen as an open
access point. Again, the user of the system would be notified of this misconfiguration insecurity
to mitigate the problem.
6.4.14 Evil Twin Detection
An evil twin attack is a simplistic variation of a man in the middle attack. In an evil twin
attack, an attacker simply uses the same SSID as another network in the area. For example, if
the attacker was sitting in a coffee shop that had free wireless internet access and that coffee
shop had a wireless access point called “Free Wireless”, all the attacker would need to do to
create an evil twin attack is broadcast with the same SSID. To any user of that wireless system
they may unknowingly connect to the attacker’s access point instead of the legitimate access
point. In doing this, attackers can eavesdrop and perform malicious attacks targeted at any
client connected to his or her illegitimate access point. From a detection standpoint, this attack
is relatively simple to detect. When a user of the system configures their probes they select
which access points (identified via BSSID) belong to them. Thus during the data analysis in the
93
Cloud Management Application, when two access points are detected that broadcast the same
SSID and one of them is not owned by the current user, then an evil twin attack has been
detected. When detected, users are notified and can either perform proactive counter attacks
or locate the attacker via proximity.
6.4.15 Man in the Middle Attack Detection
A man in the middle attack is one of most sever and difficult types of attack to detect.
Similar to the Evil Twin Attack, the MITM attack attempts to get clients to unknowingly connect
to an access point posing as someone else. Different from the Evil Twin Attack, however, the
attacker may use the same BSSID (thus appearing as the same access point), and the attacker
may even use the same 802.11 channel. Furthermore, clients can be tricked into disassociating
from one access point and reconnecting to the fake access point without any user interaction
whatsoever. A MITM attack can be detected by knowing certain pieces of information. That is,
to perform this type of attack the attacker must do at least following: they must broadcast
beacon frames (likely with identical BSSID and SSID as the target system). Additionally, they may
attempt to broadcast their beacon frames on a channel different than the target access point (to
increase performance of attacks). Lastly, the attacker may attempt to deauthenticate clients
from the target access point in an attempt to get them to re-associate to the fake access point.
Useful for detection, the attacker must broadcast at a higher power than the target access point
for clients to associate to the fake access point rather than the legitimate one. Thus, there are
four possible pieces of data that may be present at the time of a MITM attack: an increase in
beacon frames, beacon frames transmitted on multiple channels, an increase in
deauthentication frames, and an anomalous change in receive power for frames sent from the
access point being protected. Since probes collect all these pieces of information for the access
94
point they protect and transmit that information to the cloud, the MITM attack can be detected
using the following fuzzy logic algorithm: if any two or more of the above four items occurs
coincident with the others, then a MITM attack has been detected. The most likely case were
the detection happens is because the number of beacon frames being transmitted doubles and
the receive power for half of the beacon frames are anomalous. It is also obvious when beacon
frames are transmitted on two separate channels simultaneously.
Anomaly detection is done via detecting changes three standard deviations or more
from the sliding window mean. This means that for any metric the last N are recorded if no
attack is currently being detected. If a new value uploaded from a probe is three standard
deviations or more from the mean of that sliding window then that contributor is considered
active. Again, if two or more contributors are active at the same time, then the attack is
detected. For a concrete example, if the sampled count of beacon frames transmitted by the
access point being protected is 50 beacon frames with a standard deviation of 2 beacon frames,
then if on a future data collection period a probe reports 100 beacon frames, this will make the
current metric active. Additionally, if frames in that interval differ in more than three standard
deviations from the mean receive power from the sliding window, then two contributors have
been detected and the attack is detected. This fuzzy logic algorithm has been experimentally
highly accurate and is discussed in greater detail in the Results section below.
6.4.16 Performance Sampling
Though not exclusive to protection, the system also provides performance sampling
data from the probes that is aggregated and displayed for user use. So for any given channel or
access point, the user can know how many data frames are being transmitted, which devices or
networks are the most talkative, etc. This information augments the value of the system beyond
95
security into performance and augmenting the performance monitoring abilities of the probes
and the system overall is a potentially high-valued branch of future work.
96
7 Results
Driven by the design goals outlined above coupled with the user of disruptive
technology, the system described in this report has the following results. Results are discussed
both from a technical standpoint evaluating protection techniques and attack methods as well
as from a market and cost standpoint when comparing to the commercial state of the art. From
a technical perspective, the system as implemented performs strongly particularly as compared
to alternate solutions. However, direct comparison of the algorithms and techniques used in the
system as compared to the state of the art is difficult and in some cases impossible due to the
intellectual property nature of the state of the art. Nonetheless, this project focuses on
improving the state of the art in a different way: targeting new markets while maintaining an
essential and robust feature set at an order of magnitude less the typical cost.
7.1 Attack Performance
Since the commercial state of the art does not provide attack suites to the users of the
system, the performance discussed in this subsection is largely descriptive instead of
comparative. Of the categorical types of attacks provided by the system, all attacks perform as
well as the technical state of the art (in many cases it directly utilizing the technical state of the
art), and therefore are successful to their design.
7.1.1 Denial of Service
The denial-of-service attacks provided by the system are robust and universally effective
to all devices adhering to the 802.11 protocols. This universal effectiveness has been
successfully validated by testing against all major types of operating systems and devices
97
available. This includes various smartphones, tablets, laptops, desktops, etc. all of which running
various operating systems. Again the effectiveness of this attack is not device-dependent but
protocol-dependent. All forms of the denial of service attack have been independently validated
with respect to performance and the results demonstrate an expected level of success. For all
denial of service attack forms including client-based, access-point-based, channel-based, and
vendor-based, successfully render the target inert. Furthermore, the ‘Boom’ attack that renders
all wireless devices in range inert is also successful. Since a denial of service attack on all devices
and channels requires changing of channels, the success of this type of attack relies on the
speed at which a probe can cycle through the channels to repeatedly send deauthentication
frames. Experimentally in a typical environment, the probe is capable of cycling through all
channels and deauthenticating all devices in about 500 milliseconds. Thus every client has,
roughly, 500 milliseconds in which it could reconnect and continue transmitting data. However,
with all clients tested, that amount of time was not enough to re-associate and traverse through
the first levels of communication (i.e. DHCP). In extreme cases, with heavily crowded wireless
environments, it is expected that the probe channel cycle time will increase to the point that
some devices may be able to reconnect and continue traffic transmission and reception;
however, any device that made it to that point would then immediately be reset by another
deauthentication rending the connection unusable at best. In summation, the denial of service
attacks provided to users are robust and highly effective in all cases provided.
7.1.2 SSID Bomb
The success of an SSID Bomb attack depends on the probe’s ability to rapidly transmit
beacon frames into the wireless space. Using the hardware provided by the Raspberry Pi, the
probe can successfully generate between fifty and one hundred fake access points.
98
Experimentally, however, it was found that the effectiveness of the attack is more dependent on
the target hardware than the probe hardware. That is, a smartphone scanning the wireless
space may only detect fifty percent of the fake access points relative to a higher powered
machine that identifies all fake access points. In any case, the SSID Bomb attack is successful to
its purpose in demonstrating the underlying insecure principles and it confusing the scan space
for clients actively looking for a particular access point.
7.1.3 WEP Crack
The WEP Crack attack has been attempted against a several test systems running the
WEP algorithm as well as one system targeted in the real world for testing purposes (permission
was gathered in advance). In all cases, the attack was successful in identifying the WEP key.
Furthermore, all attack attempts completed in less than 5 minutes making the attack
comparable to the technical state of the art.
7.1.4 WPA Handshake Acquisition
The results with respect to gathering WPA handshakes were surprisingly successful in
testing. Numerous tests against lab access points running WPA or WPA2 were tested against all
with perfect success. Additionally, after gathering permission, the attack was used on
neighboring access points to a high level of success. In two instances a handshake was not
gathered because no clients were connected to the target (a requirement for the attack to be
successful). Furthermore, for the handshakes gathered from neighbors, dictionary attacks were
performed offline, again with permission, and two of the ten neighbors were utilizing insecure
99
passwords found in the attack’s dictionary. These neighbors were notified and the insecurities
corrected.
The resulting evaluation of the attack suite demonstrates the powerful nature of
providing these features to users. This offering is expected to be a differentiator when
comparing to other, more expensive, products that do not provide a similar capability.
7.1.5 Protection Performance
Though the primary mode of operation for the system, protection, cannot be directly
compared against the state of the art due to intellectual property conflicts, it can be evaluated
in effectiveness in protecting against the state of the art in attacking. Specifically, the evaluation
of the protection algorithms were tested using attacks generated by the Aircrack-ng attack suite
[60]. The Aircrack suite is widely considered one of the best sets of tools providing mechanisms
for all types of attacks including denial of service attacks, WEP cracking, dictionary attacks, man-
in-the-middle attacks, etc. Using this set of tools installed on a separate system the protection
algorithms were evaluated by performing attacks against the access point that a probe was
protecting. Other features of the system that act to protect wireless assets from simple
algorithmic nature were tested independently. That is, rogue access point detection,
misconfigurations, and evil twin detection were all done without using an attack suite. For
example, to validate the detection of an evil twin attack, an access point was turned on in the
system with an identical SSID to that of an SSID that the test user owned. Similarly,
misconfigurations were simulated by intentionally putting an access point owned by the test
user into a bad configuration (either manually or through a firmware reset). In all of these,
simple, functional, cases the system responded as designed by notifying the user of the event.
100
The following subsections describe experimentation that evaluates the algorithms behind more
advanced attacks.
7.1.6 Denial of Service Detection
As discussed in the Implementation section above, detection of denial of service attacks
is carried out using a simple fuzzy logic algorithm that detects if an anomaly happens in the
number of deauthentication frames sent by the access point being protect coincident with
frames received with anomalous receive power values. This algorithm was evaluated using two
attack platforms in different locations relative to the detecting probe and access point under
protection. A denial of service attack was triggered fifty times from each attacking platform
using the Aircrack toolset as the attacker. The system’s detection algorithm was successful in
detecting all one hundred attacks and successfully would have notified the user. As described
previously, denial of service attacks by nature are obvious from a data perspective, so this result
is not unexpected.
7.1.7 Man in the Middle Detection
Of the threats detected by the system described in this report, the MITM attack is the
most difficult to detect. The fuzzy logic described in the Implementation used to detect this
attack was evaluated using the Aircrack toolset. To simulate a MITM attack, the Aircrack suite
was used to create a soft access point with the same BSSID and SSID as the access point under
protection. The attack simulation was repeated from different locations and on different
channels. In all ten test cases, the MITM attack was successfully identified and the test user was
notified. Though the results using active testing showed promising results, there was one
101
suspected false alarm triggered during a three week period of the probe protecting a particular
access point. Though this alarm could have been triggered by a real MITM attack, this seemed
unlikely given the residential environment in which the alarm was triggered. Despite this likely
false alarm, the system in place successfully detects attackers even when they attempt an attack
with the same SSID, BSSID, and even on the same channel.
7.1.8 Functionality Comparison
The system described in this report has also been evaluated and designed to
incorporate a critical set of the features necessary to be competitive with the commercial state
of the art. The features provided by the system are compared to the commercial state of the art
and displayed in detail in the following table. As can be seen from the table, the system
implements all features critical for a wireless security system and avoids some features
unacceptable in that they break the asset-light paradigm underlying the project.
102
Feature Commercial SOA Asset-Light WSaaS
Rogue AP Detection and Mitigation ✓ ✓
Denial of Service Detection ✓ ✓
Evil Twin Detection ✓ ✓
Device/Vendor Classification ✓ ✓
Configuration Enforcement ✓ ✓
Real Time Alerting ✓ ✓
Man-in-the-Middle Detection ✓ ✓
Anomaly Detection ✓ ✓
Attack Suppression ✓ ✓
Attack Library ✓
Spectrum Analysis ✓
Full Channel Visibility ✓
Performance Sampling ✓ ✓
Table 1: Feature Comparison
103
In addition to being competitive with the commercial state of the art from a feature
standpoint, the system also addresses the top wireless security concerns as discussed and
agreed upon by those skilled in the art [61]. In short, the resulting system produced by the
project meets the goal of providing a critical set of features to users both from when evaluated
by comparing with competitors, but also when evaluating based on user demand.
7.1.9 Market and Cost Comparison
Paramount behind the reasoning and purpose of this project is the need for targeting a
broader market by reducing the cost of the system dramatically through leverage of disruptive
technology. The following table compares the cost of probes and of running the system as
compared to the commercial state of the art along with the market segments addressed by each
solution.
104
Table 2: Commercial Comparison
Characteristic Commercial SOA Asset-Light WSaaS
Cost of Probes (~) $1500-$2500 $100
Cost of Servers Tens of Thousands Small Monthly Fee
Technical Expertise Required Not Required
Scalability Limited to Private
Data Center
Limited to Cloud
Large Corporation Target
Market
Yes Yes
Small-Medium Business
Target Market
No Yes
Residential Target Market No Yes
105
As can be seen from the table, this project was successful in its goals. The solution provided by
this project targets a much broader market through its disruptive cost offering.
106
8 Future Work
The various forms of potential future work for this project are included in this section.
These future work vectors span technical and non-technical areas including anything from
future attacks that could be implemented to go-to-market strategies.
8.1 Data Protection Concerns Mitigation
One area that is expected to be an area of concern to any customer evaluating this
system is the protection of their data. Though with cloud adoption many customers are
becoming less averse to data leaving their private networks and being hosted in the cloud, there
are some customers where the concern is still significant. To mitigate this concern, several
solutions are possible for customers that have higher concerns about protecting their data. The
first possible solution is to host the cloud services for their probes on their network. This
solution mitigates the issue of data leaving the customer’s network, but it fundamentally breaks
the underlying assumptions backing this product: that disruptive technology can provide an
asset-light solution. Alternatively, for high-security customers, there are emerging solutions for
higher security cloud [62] that could be used to mitigate data protection concerns.
Lastly, it is possible to mitigate customer concerns through a more secure system
design. That is, there is an alternate solution that could allow for cloud analytics and all the
benefits of disruptive technology, but still allow the data to be protected by the user. One way
to implement this type of system would be to encrypt all data at the probe level and only
decrypt data after it arrives at the customer’s browser. In doing this, not even administrators to
the SaaS could obtain information about the customer’s network and wireless assets. This
mechanism does pose some challenges in that calculations in the cloud would need to be
107
performed on encrypted data, but many of these calculations could be still be done in encrypted
space using homomorphic encryption techniques [63]. However, there are some features of the
system that require knowledge of the system (i.e. detecting misconfigurations) that would need
to be done in unencrypted space.
A potentially simpler solution to the homomorphic encrypted calculations would be to
only encrypt the sensitive data. That is, customers are likely only going to care about sensitive
pieces of information about their system including things like IP addresses, MAC addresses,
locations, etc. Thus, a mechanism could be devised such that all the sensitive pieces of
information remain encrypted from probe to browser, but other, non-sensitive pieces of
information are calculated on as plaintext. For example, the cloud calculations do not need to
know the IP address or MAC address of a particular device, but could perform calculations using
an encrypted form of the MAC/IP.
To achieve a mechanism for encrypting sensitive data in transit and in the cloud, the
following steps could be implemented. First, a mechanism for customers to insert key(s) into
their probes would need to be implemented. While this could be done through the claim
process, transmitting the keys through the cloud applications defeats the purpose of only
allowing customers to view their data. There are many ways this could be implemented – for
example, the probes could have a simple web management interface when you point a browser
at them (much like a consumer grade router) and key(s) could be inserted into the device
through that interface. Second, as part of the client-side JavaScript, the user of the system
would need to be prompted to insert some decryption key so that data is viewable in a useable
format for the customer.
While the mechanism described in this subsection would need refinement, if customer
demand presented the need, a solution is possible to help mitigate concerns about data
108
protection while still allowing for the underlying design goals to be upheld by leveraging
disruptive technology.
8.2 Future Attacks
Omitted from the initial release of this system are two attacks that could be
implemented if there was customer demand and or a legitimate reason for their use. The first
attack that was omitted was a full WPA Dictionary attack. Currently the system will perform the
first part of this attack with a WPA Handshake Acquisition, but does not carry out the dictionary
attack. Originally the attack suite was designed to upload that handshake to the cloud which
would then parallelize the dictionary attack to many cloud virtual machines to more quickly find
a solution. Development on this feature was started but put on hold for two reasons. First, the
cloud cost to perform computations of that magnitude become expensive. While this could be
an extra charge for customers to use, the value proposition did not hold at least for the first
release. The second reason for development being put on hold was the discovery of other
systems that perform a similar service [64] against which this project could not easily find
differentiation. The second attack that was omitted from the first release was an automated
man-in-the-middle attack. This attack would perform all the necessary steps to attempt a MITM
attack including setting up a fake access point on the probe that matches a target access point,
deauthenticating clients and getting them to re-associate to the fake access point. While this
attack is relatively simple in nature it was put on hold until a legitimate use case could be
thought of that would benefit customers. That is, other than performing malicious activities, no
other reason could be found to implement this attack and therefore it was slated for future
work until a legitimate reason for its use could be found.
109
8.3 Go to Market Strategy
Though the system has been implemented and validated from a technical standpoint, if
this solution were to be made commercially available, the largest remaining problem is how to
go to market. Meaning – what is the strategy that informs customers that the solution exists at
all and why they should purchase it? This problem remains one of the most difficult problems
for any new solution, but three strategies are outlined in this subsection. The first strategy
would be to attempt to bootstrap the solution into the marketplace. This would be the most
costly and difficult solution and would involve working through online presence and marketing
campaigns to attempt and attract customers. The second strategy would be to try and generate
awareness through some kind of crowdfunding site. That is, a Kickstarter [65] campaign might
be useful to attract enthusiasts as the initial user base and, if successful, would generate a large
amount of awareness. Lastly, this solution could attempt to partner with an existing
infrastructure and leverage existing sales systems. For example, to target the residential market
segment, one could attempt to partner with a company like ADT [66] who could bundle the
solution into home security systems. None of these go-to-market models are mutually exclusive,
but this problem remains as the largest barrier to becoming market competitor.
8.4 Mobile Application
Discussed throughout this report is the notion of disruptive technology and leveraging
that technology. However the leverage discussed in this report focused almost exclusively on
leveraging cloud computing. Thus a significant gap in the provided service is mobile
consumption. Though Cloud Web Application is designed to be viewable on mobile devices with
small screens, the experience could be further improved by writing native mobile applications
110
for the major mobile operating systems that consume data from the cloud directly via an API.
Depending on customer demand mobile application can and will be created to meet that need.
111
9 Conclusion
As one contemplates the severity of how attackers can compromise 110 million
customers, the reality is that the malicious are highly skilled, creative, resourceful, and
motivated; and with those characteristics the imperative for protection is as strong as it ever has
been. Furthermore, when network access is the first line of defense and the wireless mediums
we use are the most vulnerable to attacks, there is a resounding need for solutions that protect
this space. Yet, even as the state of the art has solved much, the premises on which the state of
the art was created are now disrupted by the dramatic changes we have seen in the past few
years. With that disruption, a new solution has arisen that allows for a wider market segment to
be addressed at a fraction of the cost. The system provided by this project is not only for the
large, wealthy, and technologically advance customers, but for all users that need to protect
their wireless assets. The re-imagination of wireless security starts with this system and provides
a powerful new tool in the wireless security marketplace.
112
10 References
[1] D. Douglas, “Retailers toCongress: There’s no end in sight for credit card breaches,”
Washington Post.
[2] B. Krebs, “A First Look at the Target Intrusion, Malware — Krebs on Security.” .
[3] M. Jewell, “T.J. Maxx theft believed largest hack ever - Technology & science - Security |
NBC News,” 30-Mar-2007.
[4] G. Berg, M. Freeman, and K. Schneider, “Analyzing the TJ Maxx Data Security Fiasco,” CPA
J.
[5] “IEEE-SA -IEEE Get 802 Program - 802.11: Wireless LANs.” [Online]. Available:
http://standards.ieee.org/about/get/802/802.11.html. [Accessed: 09-Feb-2014].
[6] “Wi-Fi Alliance.” [Online]. Available: http://www.wi-fi.org/. [Accessed: 09-Feb-2014].
[7] “AirMagnet Enterprise.” [Online]. Available: http://www.flukenetworks.com/enterprise-
network/wireless-network/AirMagnet-Enterprise. [Accessed: 09-Feb-2014].
[8] S. Thakur and A. Bodhe, “RAPD Algorithm: Detection of Rogue Access Point in Wireless
Network.”
[9] G. Chen, H. Yao, and Z. Wang, “Research of wireless intrusion prevention systems based on
plan recognition and honeypot,” in Wireless Communications & Signal Processing, 2009.
WCSP 2009. International Conference on, 2009, pp. 1–5.
[10] G. Chen, H. Yao, and Z. Wang, “An intelligent WLAN intrusion prevention system based on
signature detection and plan recognition,” in Future Networks, 2010. ICFN’10. Second
International Conference on, 2010, pp. 168–172.
[11] A. Singhrova, “A host based intrusion detection system for DDoS attack in WLAN,” in
Computer and Communication Technology (ICCCT), 2011 2nd International Conference on,
2011, pp. 433–438.
113
[12] N. Tsarmpopoulos, I. Kalavros, and S. Lalis, “A low-cost and simple-to-deploy peer-to-peer
wireless network based on open source linux routers,” in Testbeds and Research
Infrastructures for the Development of Networks and Communities, 2005. Tridentcom
2005. First International Conference on, 2005, pp. 92–97.
[13] “AirDefense Services Platform - Motorola Solutions USA.” [Online]. Available:
http://www.motorolasolutions.com/US-
EN/Services/Run/Network+Infrastructure+Management/IT/AirDefense_Services_Platform.
[Accessed: 09-Feb-2014].
[14] “Motorola AirDefense Services Platform.” .
[15] “Samir Palnitkar - Wikipedia, the free encyclopedia.” [Online]. Available:
http://en.wikipedia.org/wiki/Samir_Palnitkar. [Accessed: 09-Feb-2014].
[16] “AirTight Networks.” [Online]. Available: http://www.airtightnetworks.com/. [Accessed:
09-Feb-2014].
[17] D. C. King, P. Bhagwat, and S. Gogate, Method and system for monitoring a selected region
of an airspace associated with local area networks of computing devices. Google Patents,
2012.
[18] “AirMagnet.” [Online]. Available: http://en.wikipedia.org/wiki/AirMagnet. [Accessed: 09-
Feb-2014].
[19] “AirMagnet for Cisco Small Business.” [Online]. Available:
http://www.flukenetworks.com/enterprise-network/wireless-network/AirMagnet-
Planner/planCS. [Accessed: 09-Feb-2014].
[20] W. Blackwell, “Method and system for analyzing rf signals in order to detect and classify
actively transmitting rf devices,” 2010.
[21] J. D. Sundar, C. C. Kuan, and M. Wu, “Tracing an access point in a wireless network,” 2013.
114
[22] D. Au, C. C. Kuan, and M. Wu, “Detecting a hidden node in a wireless local area network,”
2004.
[23] C. C. Kuan, M. Wu, and D. Au, “Detecting an unauthorized station in a wireless local area
network,” 2012.
[24] D. Au, C. C. Kuan, and M. Wu, “Monitoring a local area network,” 2004.
[25] “Mary Meeker — Kleiner Perkins Caufield Byers.” [Online]. Available:
http://www.kpcb.com/partner/mary-meeker. [Accessed: 09-Feb-2014].
[26] M. Meeker, “2011 Internet Trends — Kleiner Perkins Caufield Byers.” [Online]. Available:
http://www.kpcb.com/insights/2011-internet-trends. [Accessed: 09-Feb-2014].
[27] M. Meeker, “2012 Internet Trends — Kleiner Perkins Caufield Byers.” [Online]. Available:
http://www.kpcb.com/insights/2012-internet-trends. [Accessed: 09-Feb-2014].
[28] M. Meeker, “2012 Internet Trends (Update) — Kleiner Perkins Caufield Byers.” [Online].
Available: http://www.kpcb.com/insights/2012-internet-trends-update. [Accessed: 09-
Feb-2014].
[29] “Big Data: The New Natural Resource | The Big Data Hub.” [Online]. Available:
http://www.ibmbigdatahub.com/infographic/big-data-new-natural-resource. [Accessed:
09-Feb-2014].
[30] J. Sunshine, S. Egelman, H. Almuhimedi, N. Atri, and L. F. Cranor, “Crying Wolf: An
Empirical Study of SSL Warning Effectiveness.,” in USENIX Security Symposium, 2009, pp.
399–416.
[31] “MongoDB.” [Online]. Available: https://www.mongodb.org/. [Accessed: 20-Mar-2014].
[32] “Leading NoSQL Database | MongoDB.” [Online]. Available:
http://www.mongodb.com/leading-nosql-database. [Accessed: 20-Mar-2014].
[33] “Redis.” [Online]. Available: http://redis.io/. [Accessed: 20-Mar-2014].
115
[34] “Email Delivery & Transactional Email Service | SendGrid.” [Online]. Available:
http://sendgrid.com/. [Accessed: 20-Mar-2014].
[35] “RESTful Web services: The basics.” [Online]. Available:
https://www.ibm.com/developerworks/webservices/library/ws-restful/. [Accessed: 20-
Mar-2014].
[36] “node.js.” [Online]. Available: http://nodejs.org/. [Accessed: 20-Mar-2014].
[37] “Express - node.js web application framework.” [Online]. Available: http://expressjs.com/.
[Accessed: 20-Mar-2014].
[38] “AngularJS — Superheroic JavaScript MVW Framework.” [Online]. Available:
http://angularjs.org/. [Accessed: 20-Mar-2014].
[39] “AngularJS: Tutorial: 4 - Two-way Data Binding.” [Online]. Available:
http://docs.angularjs.org/tutorial/step_04. [Accessed: 20-Mar-2014].
[40] “Jade - Template Engine.” [Online]. Available: http://jade-lang.com/. [Accessed: 20-Mar-
2014].
[41] “Bootstrap.” [Online]. Available: http://getbootstrap.com/. [Accessed: 20-Mar-2014].
[42] “jQuery.” [Online]. Available: http://jquery.com/. [Accessed: 20-Mar-2014].
[43] “Highcharts - Interactive JavaScript charts for your webpage.” [Online]. Available:
http://www.highcharts.com/. [Accessed: 20-Mar-2014].
[44] “Font Awesome, the iconic font designed for Bootstrap.” [Online]. Available:
http://fontawesome.io/. [Accessed: 20-Mar-2014].
[45] “Heroku | Cloud Application Platform.” [Online]. Available: https://www.heroku.com/.
[Accessed: 09-Feb-2014].
[46] N. Provos and D. Mazieres, “Bcrypt Algorithm,” 1999.
116
[47] “Passport - Simple, unobtrusive authentication for Node.js.” [Online]. Available:
http://passportjs.org/. [Accessed: 20-Mar-2014].
[48] W. Stallings and L. Brown, Computer Security: Principles and Practice. .
[49] “Pub/Sub – Redis.” [Online]. Available: http://redis.io/topics/pubsub. [Accessed: 20-Mar-
2014].
[50] “AWS | Amazon CloudFront CDN - Content Delivery Network & Streaming.” [Online].
Available: http://aws.amazon.com/cloudfront/. [Accessed: 20-Mar-2014].
[51] “FAQs | Raspberry Pi.” [Online]. Available: http://www.raspberrypi.org/faqs#introWhatIs.
[Accessed: 09-Feb-2014].
[52] “ALFA NETWORK Inc.” [Online]. Available:
http://www.alfa.com.tw/products_show.php?pc=34&ps=21. [Accessed: 20-Mar-2014].
[53] “OpenWrt.” [Online]. Available: https://openwrt.org/. [Accessed: 20-Mar-2014].
[54] “BeagleBoard.org - BeagleBone Black.” [Online]. Available:
http://beagleboard.org/Products/BeagleBone+Black. [Accessed: 20-Mar-2014].
[55] J. Hermann, Forking a Daemon Process on Unix. .
[56] “Cisco Wireless Control System Configuration Guide, Release 7.0.172.0 - Chapter 20: wIPS
Policy Alarm Encyclopedia [Cisco Wireless Control System] - Cisco.” [Online]. Available:
http://www.cisco.com/c/en/us/td/docs/wireless/wcs/7-
0MR1/configuration/guide/WCS70MR1/wips_ench.html. [Accessed: 20-Mar-2014].
[57] H. I. Bulbul, I. Batmaz, and M. Ozel, “Wireless network security: Comparison of WEP (wired
equivalent privacy) mechanism, WPA (wi-fi protected access) and RSN (robust security
network) security protocols,” in Proceedings of the 1st international conference on
Forensic applications and techniques in telecommunications, information, and multimedia
and workshop, 2008, p. 9.
117
[58] “T.J. Maxx Data Theft Likely Due To Wireless ‘Wardriving’ - InformationWeek.”[Online].
Available: http://www.informationweek.com/tj-maxx-data-theft-likely-due-to-wireless-
wardriving/d/d-id/1054964? [Accessed: 20-Mar-2014].
[59] S. Fluhrer, I. Mantin, and A. Shamir, “Weaknesses in the key scheduling algorithm of RC4,”
in Selected areas in cryptography, 2001, pp. 1–24.
[60] “Aircrack-ng.” [Online]. Available: http://www.aircrack-ng.org/. [Accessed: 20-Mar-2014].
[61] L. Phifer, “Top Ten Wi-Fi Security Threats - eSecurity Planet,” eSecurity Planet.
[62] “AWS CloudHSM.” [Online]. Available: http://aws.amazon.com/cloudhsm/. [Accessed: 20-
Mar-2014].
[63] “Homomorphic Encryption - MIT Technology Review.” [Online]. Available:
http://www2.technologyreview.com/article/423683/homomorphic-encryption/.
[Accessed: 20-Mar-2014].
[64] “CloudCracker :: Online Hash Cracker.” [Online]. Available:
https://www.cloudcracker.com/. [Accessed: 20-Mar-2014].
[65] “Kickstarter.” [Online]. Available: https://www.kickstarter.com/. [Accessed: 20-Mar-2014].
[66] “ADT Security Systems: Home Automation, Alarms & Surveillance.” [Online]. Available:
http://www.adt.com/. [Accessed: 20-Mar-2014].
118
11 For Appendices Please See Separate Appendix Document