an auditing tool for wi-fi or wired ethernet connections by
TRANSCRIPT
An Auditing Tool for Wi-Fi or Wired Ethernet Connections
by
Matthew Sullivan
A creative component submitted to graduate faculty
in partial fulfillment of the requirements for the degree of
MASTER OF SCIENCES
Co-majors: Computer Engineering; Information Assurance
Program of Study Committee:
Doug W. Jacobson, Major Professor
Thomas E. Daniels
George T. Amariucai
Joseph Zambreno
Iowa State University
Ames, Iowa
2013
ii
ABSTRACT
In 2010, security researcher Eric Butler introduced Firesheep, a Firefox extension for
performing session sidejacking attacks over open Wi-Fi networks. Firesheep specifically
targeted major websites, including Facebook, Twitter, and Amazon – all of which used SSL/TLS
for authentication, but then immediately dropped down to unencrypted HTTP for the duration of
the user’s session. Firesheep made for a strong proof-of-concept, but lacked the support and
direction needed in order to consider it a true network auditing utility.
This project, Cookie Cadger, was created as the spiritual successor to Firesheep. Cookie
Cadger takes the concepts that Firesheep was built upon and extends them significantly, allowing
for robust auditing of authenticated HTTP requests sent over unencrypted channels. Cookie
Cadger features automated detection of session cookies for many websites and frameworks,
replay of a session into the browser, and the easy export of session data into other security
applications or reports. Cookie Cadger utilizes the Wireshark suite and Java to deliver a cross-
platform, open-source auditing platform for monitoring wired Ethernet or unencrypted 802.11
(Wi-Fi) connections transmitting session data via HTTP.
iii
TABLE OF CONTENTS
ABSTRACT .................................................................................................................................... ii
LIST OF FIGURES ........................................................................................................................ v
CHAPTER 1. OVERVIEW ........................................................................................................... 1
1.1 Introduction ...................................................................................................................... 1
1.2 Motivation ........................................................................................................................ 3
1.2.1 Web Application Penetration Testing ....................................................................... 4
1.2.2 Assessment of End-User Security Practices ............................................................. 6
1.2.3 Enterprise Network Penetration Testing ................................................................... 6
1.2.4 User Education .......................................................................................................... 7
1.3 Outline .............................................................................................................................. 7
CHAPTER 2. RELATED WORK ................................................................................................. 9
2.1 Manual Session Cookie Interception and Replay ............................................................ 9
2.2 Ferret and Hamster ......................................................................................................... 15
2.3 Firesheep ........................................................................................................................ 15
CHAPTER 3. DESIGN & IMPLEMENTATION ....................................................................... 19
iv
3.1 Language Selection ........................................................................................................ 20
3.2 Packet Capture Platform................................................................................................. 20
3.3 Data Acquisition Methods .............................................................................................. 23
3.4 Analysis of Clients, Domains, and Requests ................................................................. 25
3.4.1 Layout ..................................................................................................................... 25
3.4.2 Data Export to Clipboard ........................................................................................ 27
3.4.3 Real-time Filtering .................................................................................................. 28
3.5 Request Replay into Browser Session ............................................................................ 29
3.6 Automatic Session Detection ......................................................................................... 33
3.7 Database Storage ............................................................................................................ 37
3.8 Headless Operation ........................................................................................................ 39
CHAPTER 4. FUTURE DIRECTION ......................................................................................... 41
CHAPTER 5. CONCLUSION...................................................................................................... 43
BIBLIOGRAPHY ......................................................................................................................... 45
ACKNOWLEDGEMENTS .......................................................................................................... 48
v
LIST OF FIGURES
Figure 1 – A target authenticates to a website and proceeds to browse over HTTP .................... 10
Figure 2 – An attacker uses tcpdump to intercept a session cookie from an HTTP request ........ 11
Figure 3 – Internet Explorer before session cookie modification ................................................. 12
Figure 4 – Modifying Internet Explorer cookie data with IECookiesView.................................. 13
Figure 5 – Intercepted session cookie loaded into Internet Explorer ............................................ 14
Figure 6 – Firesheep intercepting and replaying a valid Facebook session cookie ...................... 17
Figure 7 – Multiple capture device support .................................................................................. 24
Figure 8 – Import from existing capture file ................................................................................. 25
Figure 9 – Client information tracking ......................................................................................... 26
Figure 10 – Request information tracking .................................................................................... 27
Figure 11 – Exporting request data to clipboard ........................................................................... 28
Figure 12 – Real-time filtering ..................................................................................................... 29
Figure 13 – Replay of an individual request ................................................................................. 30
Figure 14 – Successful session sidejacking of eBay account ....................................................... 32
Figure 15 – Modification of a request before replay into browser ............................................... 33
Figure 16 – A valid Facebook session is loaded using session detection ..................................... 35
Figure 17 – A Drupal installation is identified using session detection ....................................... 37
Figure 18 – Configuration settings for MySQL database storage ................................................ 38
Figure 19 – Demonstration of headless mode ............................................................................... 39
1
CHAPTER 1. OVERVIEW
1.1 Introduction
The Hypertext Transfer Protocol, or HTTP, is a protocol designed for sending pages of
information and other media across the Internet from a web server to a client web browser.
HTTP is a stateless protocol, meaning that it cannot keep track of sessions or connections
inherently. In 1994 Lou Montulli, an engineer with Netscape, decided to add a method by which
browsers could be repeatedly and reliably identified and authenticated to a particular browsing
session [1]. This concept, which he named “cookies” has been implemented in to browsers ever
since.
Nearly twenty years later, almost all modern session management mechanisms use
cookies to match a user’s web browser to an ongoing session on the server, following a basic
pattern:
1. A user requests the login page.
2. The web server starts session management with an ID to match to this client.
3. The web server authenticates the client and sends this ID as a cookie to the client.
4. The client sends this cookie back (with the ID) per each request.
5. The web server provides a custom response tailored to the user, based off of this ID.
2
Initially, cookies were used for basic user behavior tracking, such as checking if the
visitor was a first-time or returning guest. Before long, session management evolved to keeping
track of online shopping carts, data-driven behavior analytics, and tracking of user
authentication.
As the web matured, so did its security. Throughout the early 90s, Netscape pioneered
security on the transport layer by introducing Secure Sockets Layer (SSL). SSL provides both
encryption and authentication through a public-key infrastructure. Today, this technology is
most commonly used for transmitting user credentials securely from the client to the web server.
SSL v3.0, which is still considered cryptographically trustworthy to this day, was
proposed in March 1996 and widely adopted soon after [2]. In 1999, Transport Layer Security
(TLS) was proposed as a robust replacement for SSL which added additional security features
[3]. These developments drove most sites providing authentication to utilize either SSL or TLS
for the exchange of user credentials. However, after finishing authentication, these sites
typically would drop back down to unencrypted HTTP. So while SSL/TLS provided password
protection, it was not being utilized for session protection. This problem continues today,
despite regular pleas from the information security community to protect all session data with
SSL/TLS. Most providers refuse to transition, citing the additional cost of capacity to deal with
strongly-keyed encryption and decryption [4].
3
Session sidejacking was developed as a method to exploit this vulnerability. In a session
sidejacking attack, the attacker monitors the unencrypted traffic for session cookies that uniquely
identify the client to the web server. The attacker then steals these values and loads them into
their own web browser, effectively masquerading as the victim.
Session sidejacking has been possible since the introduction of session management
utilizing HTTP cookies. The availability of unencrypted Wi-Fi, however, exponentially
increased the risk of session sidejacking. Previously an attacker with network access would have
to be man-in-the-middling the connection in order to intercept and save cookie data. Wireless
networking made this significantly easier, requiring only that the attacker be in the same general
area as the target in order to intercept Wi-Fi signals broadcast from the target device.
While assessing the availability of auditing tools related to session sidejacking, we found
that viable options were few and far between. Additionally, none of these offered cross-platform
support, and almost all had been abandoned by their developers long ago.
1.2 Motivation
On the surface, a session sidejacking tool may seem like nothing more than another toy to
enable malicious individuals to prey on unsuspecting users. In reality, such tools are useful for
both enterprise penetration testing and user education. Creators of these tools, however, must
find a balance. The tool must be easy to use and intuitive in functionality and design.
Simultaneously, the tool should be difficult enough to set up that a “script kiddie” (a person who
4
can run a script but lacks the technical knowledge behind how an attack is performed) is unable
to effectively utilize it. It is worth noting, though, that even without the use of a specialized
session sidejacking tool, session cookie theft is not that hard to perform, as the procedures are
well documented online.
Penetration testers, web application developers, and network administrators alike can
glean immediate benefit from using automated detection utilities to find issues before those
issues go into production systems, or to identify issues that have already entered the network.
With that in mind, some of the most common use cases for a session sidejacking utility are listed
below.
1.2.1 Web Application Penetration Testing
Many web applications unintentionally request insecure resources from a page served via
SSL/TLS. For example, many pages and blogs in the Microsoft MSDN website (a popular
website for assistance with Microsoft technologies) attempt to load and invoke JavaScript from
an unencrypted HTTP connection, even when the page itself is served over SSL/TLS [5]. This is
a major security concern for two reasons:
1. A man-in-the-middle attacker could modify the JavaScript in-transit without causing a
security warning or certificate failure. This is possible because the server for these
resources is not being authenticated.
5
2. Any session cookies applicable for the domain msdn.microsoft.com will be transmitted to
the server for each request to msdn.microsoft.com/*. If resources (such as images, CSS,
or JavaScript) are being served from /* on the domain and requested via HTTP, and the
session cookie is not marked as “secure” (only transmit via secure channel), the session
cookie will be transmitted without any encryption, and therefore will be vulnerable to
interception.
Session sidejacking utilities can detect this leakage and allow a security analyst to
demonstrate this problem in a visually-engaging manner to developers or management. This can
help to illustrate the necessity of quickly finding a solution to the problem.
Some session sidejacking utilities can be installed server-side, such as on a public-facing
webserver. These utilities can be particularly useful on systems which should always be serving
specific pages over SSL/TLS, but may be including insecurely-transmitted content from the web
server or elsewhere. A session sidejacking utility could be utilized in this situation to quickly
and easily highlight which resources are being requested over these insecure channels, and if
session cookie data is leaking out with those requests. This is a capability of packet capture
utilities as well, such as tcpdump or Wireshark. Unfortunately, using the aforementioned utilities
for this type of auditing can be cumbersome to get set up and running properly, due to the
complexity involved with filtering out noisy data which is not part of the overall investigation.
6
1.2.2 Assessment of End-User Security Practices
Session sidejacking utilities can also be useful for analysis of end-user security practices
within an organization. In order to perform content filtering, many large enterprises actively
man-in-the-middle their users’ traffic (and this is typically acknowledged, in writing, by the
employee). The use of session sidejacking utilities by IT security professionals on these
networks can be beneficial in ensuring that employees are only transmitting company data over
secure connections that are resistant to tampering. Data gleaned from such investigations can
then be used to illustrate the importance of using SSL/TLS encrypted connections by providing
real-world examples that employees can see and interact with.
1.2.3 Enterprise Network Penetration Testing
Enterprise network penetration testing typically involves performing a security
assessment across multiple systems in a company for the purposes of determining security
weaknesses or outright vulnerabilities. These engagements are typically very complex, time-
consuming, and require a vast array of software. Depending on the requirements of the
assessment, session sidejacking may be used to aid in the discovery of information or the
escalation of privilege. Session sidejacking is just one of many avenues of attack for an auditor
to use against a computer system. Typically, the end-goal of such assessments is to gain
administrative access to as many systems as possible. This type of assessment is particularly
important for organizations which rely heavily on web-based software to conduct business.
7
1.2.4 User Education
Finally, user education is the strongest use case for session sidejacking utilities. In fact,
Cookie Cadger was originally envisioned as an educational tool to be used by the Iowa State
University Information Assurance Student Group for illustrating to students how to maintain
their safety and privacy online.
Session sidejacking utilities allow security analysts to demonstrate the importance of
using SSL/TLS, especially over open Wi-Fi networks. This type of education is a must-have for
companies with employees who are regularly in airports, coffee shops, or other open networks.
Without this hands-on training, employees might not be aware that their actions can be easily
monitored and that company data could be stolen.
Finally, a demonstration of session sidejacking allows the user to easily understand the
repercussions of using unencrypted channels. Most users are aware that using open Wi-Fi and
HTTP could allow an attacker to “see” your information. However it is much harder to illustrate
to a user how an attacker would then be able to steal your session and become your online
identity. This small change in thinking is often enough motivation to a user to alter their online
behaviors when on open Wi-Fi or other untrusted networks.
1.3 Outline
The remaining chapters of this paper will be used to discuss related work, design and
implementation, and future considerations. In covering related work, chapter two will provide
8
examples of previous research and projects in the session sidejacking field. This discussion will
highlight why these existing methods fail to meet the growing needs of the security community.
Chapter three will cover the design and implantation of this project. This section details the
architectural decisions behind Cookie Cadger’s development before moving into a detailed walk-
through of the software’s features. Chapter four will cover future directions for the software and
the vision for its continued development, followed by a brief conclusion.
9
CHAPTER 2. RELATED WORK
2.1 Manual Session Cookie Interception and Replay
Session sidejacking has been a known vulnerability ever since the introduction of HTTP
cookies back in the early 1990s. Historically, though, session sidejacking has been a fairly
manual process.
The first step in session sidejacking is to capture HTTP traffic. Traffic capture was an
easier process back when networking equipment still relied on hubs for signal transport. An
attacker could simply plug in to the network and sniff out all the traffic on the wire as the hub
replayed the electrical signal. Later, network switching came into the picture, which complicated
the process by requiring the attacker to perform more intrusive operations in order to man-in-the-
middle the victim (such as an ARP cache poisoning attack). By the mid-2000s, though, Wi-Fi
had become pervasive enough to blow the top right off of privacy. Now anyone with the proper
tools in proximity of you could intercept your data packets.
Next, an attacker needs to read in the packets and search for the HTTP GET request from
client to server. In the days before Wireshark (previously known as Ethereal), the standard
10
UNIX application tcpdump was the easiest method for quickly dumping session cookies out of
intercepted HTTP requests [6].
In the following example, tcpdump monitors the connection in use by the Chrome
browser. This browser is logged into the Information Assurance Center’s website as a Drupal
administrator, and is accessing the site over HTTP, meaning that the session cookie is able to be
intercepted. A tcpdump command is crafted to deconstruct packets received on port 80 with
words matching “Cookie” or “Host”. The system will display the first two results and then exit
immediately. See figure 1 below.
Figure 1 – A target authenticates to a website and proceeds to browse over HTTP
11
Figure 2 – An attacker uses tcpdump to intercept a session cookie from an HTTP request
It may not be immediately clear as to what information from figure 2 is important to the
sidejacking attack, as the domain has set other cookies for various tracking services (Google
Analytics) and helper cookies to communicate the availability of JavaScript on the client. The
cookie of interest in this example is:
This cookie is the session cookie. The cookie was set by the web server and transmitted to our
client. Upon asking for another page on the web server, the session cookie was transmitted back
to the server, matched to the corresponding tcpdump rule, and shown on the screen. Now that
the attacker has the session cookie, they may replay it by loading it into a browser session.
In this example, the Internet Explorer web browser is used as the attacker’s browser of
choice. The attacker would begin by loading the Information Assurance Center’s website in the
browser. Note that the user is not logged in (black “admin bar” is not present).
SESS3881200b366096014d6fbafc8838a890=s9amjqt3s0mc3a3d48sj8nsvp0
12
Figure 3 – Internet Explorer before session cookie modification
Now the attacker modifies the Internet Explorer cookies to inject this session cookie value into
their own browser. For this, the attacker would likely use IECookiesView [7], a free cookie
modification utility for Internet Explorer which has been available since early 2002.
13
Figure 4 – Modifying Internet Explorer cookie data with IECookiesView
After modifying the browser’s cookie data to reflect the cookie captured by tcpdump, the
attacker loads the browser again and navigates to the targeted website.
14
Figure 5 – Intercepted session cookie loaded into Internet Explorer
On this visit the attacker’s session cookie now matches a known session on the server –
the session logged in as “msulliv”. The attacker never required knowledge of a user name or
password. Instead, the session cookie was sufficient for providing the attacker full
administrative access to the web server. This process, while highly effective, requires a
considerable amount of time. Each session cookie has to be intercepted, inspected, and then
meticulously replayed into the browser. Despite the time commitment required, this was the
primary method for conducting session sidejacking attacks for more than a decade.
15
2.2 Ferret and Hamster
In 2007, security researcher Robert Graham demonstrated his session sidejacking
software, “Ferret and Hamster”, during the Black Hat security conference [8]. Graham’s
software quickly made waves in the computer security field for its simplistic capturing and
replaying capabilities.
In Graham’s application suite, the attacker first starts the Ferret application. Ferret
dutifully captures network traffic while looking for HTTP requests. If an HTTP request is found
to contain cookie data, Ferret saves this information to a database. Hamster reads from this
database and allows the attacker to load sites into their browser as if they were in the victim’s
own browser session. However, proper operation of Hamster does require properly configuring
the browser to utilize a local proxy server.
The Ferret and Hamster approach quickly gained the attention of those in the security
community, and was widely praised for introducing a significantly less labor-intensive method
for session sidejacking [9]. This was particularly noteworthy at the time because most e-mail
services (such as Gmail and Hotmail) were not offering SSL/TLS security to clients.
2.3 Firesheep
In 2010, security researcher Eric Butler introduced Firesheep during the Toorcon security
conference in San Diego, California. Firesheep was created as a Firefox extension for
performing session sidejacking attacks over open Wi-Fi networks [1]. Firesheep specifically
16
targeted major websites, including Facebook, Twitter, and Amazon. In 2010, all of these sites
used SSL/TLS for authentication, but would then establish an insecure session over HTTP which
was used for the duration of the user’s browsing session.
For maximum effect, Firesheep would scrape the page for content in order to come up
with information about the user, typically including their name and profile picture. This identity
would then be made available to a Firesheep user through the Firefox sidebar. The sidebar
would allow the replay of an identity simply by clicking the user’s name. Firesheep would then
instruct Firefox to purge all existing cookies and load the victim’s cookies instead. Finally,
Firesheep would request the page.
Facebook’s ubiquity caused it to be the most popular target for Firesheep users. Given
that millions of Americans were using Facebook, media attention was quick to follow [10].
Before long, most professionals involved with the tech industry not only knew about Firesheep –
but were also concerned about it.
17
Figure 6 – Firesheep intercepting and replaying a valid Facebook session cookie
Butler was very upfront about his goals with Firesheep, summarizing the attention by
making the following statement on his personal website [11]:
Because of its simplicity, Firesheep has already succeeded in demonstrating the risks of
insecure websites to a much wider audience than any previous tool, in a single day.
Many companies make a business, not technical, decision to not implement security due to
either perceived or actual costs. It is our opinion that turning a blind eye to customer privacy
and security is never good for business, and we hope the people making these decisions will
begin to agree.
18
Firesheep was more of a proof-of-concept toy than a security auditing utility. After
releasing Firesheep’s source code, Butler discontinued his efforts on the project and moved on.
The software quickly became unusable, compatible with only 32-bit Windows or OS X, and
requiring Firefox 3. Sites targeted by Firesheep quickly offered users the option to always use
SSL/TLS, and today many of these websites rollover all users to secure connections by default.
The fact remains that Firesheep was more of a toy than an auditing utility. While good
for targeting some of the larger website on the Internet, Firesheep lacked the ability to save or
later present the data in a meaningful way. Additionally, getting the utility up and running across
multiple operating systems was a major issue. Thus, Cookie Cadger was created as the spiritual
successor to Firesheep with the goal of taking session cookie auditing utilities to the next level.
19
CHAPTER 3. DESIGN & IMPLEMENTATION
Cookie Cadger’s origins are rooted in a class project for a wireless network security
course offered at Iowa State University. In this class, students were given the task of creating a
project associated with wireless networks or wireless security. In February 2012, Cookie Cadger
was conceived in the following project proposal:
To educate users on the issues surrounding the use of unencrypted Wi-Fi, I propose
creating a new Linux-based plugin for Firefox which monitors a wireless channel in
promiscuous mode. This utility would detect HTTP GET requests and would extract all
header information, including cookies or authorization information. The utility will then
open this display page on the screen in Firefox while replaying the cookie and
authorization information back to the server, thereby preserving session information (such
as authenticated pages on Facebook, Twitter, and other websites) and making a more
impacting demo for user education.
Once completed, this utility will be used for demos by the Information Assurance Student
Group and Information Assurance departments at ISU to bring interest to security and
further the groups’ outreach efforts. It will also be released as open-source software for
other security interest groups to use in their educational efforts.
20
Over the next 16 months, Cookie Cadger developed from a single main method into
6,000 lines of code spanning three major versions. This chapter details the design of Cookie
Cadger and explains the implementation of its feature set.
3.1 Language Selection
The number one goal for Cookie Cadger is to support cross-platform compatibility that
primarily targets Linux, Windows, and Mac OS X. Further, if possible, Cookie Cadger should
run using the same set of binary or source files across all of these platforms. The obvious choice
to fit these requirements is Java, as it is already a highly-popular framework for cross-platform
applications. As an additional perk, Java applications can be distributed as a single JAR binary
file, meaning that this single binary file should run on all platforms without modification.
Cookie Cadger is primarily a graphical tool, and the Java Swing libraries have been
selected to provide a user interface. While Swing is somewhat aged, its use keeps Cookie
Cadger from requiring a previous install of other popular frameworks, like Gtk+ or Qt.
3.2 Packet Capture Platform
With any networking-related project, often the biggest hurdle is finding a cross-platform
mechanism to provide packet capture or analysis support. During the development of Cookie
Cadger’s first iteration, the software utilized the jNetPcap Java wrapper for libpcap to facilitate
packet capture [12]. However, this library presented four very large concerns:
21
1. jNetPcap has not been updated since fall of 2010, and the maintainer is inactive.
2. jNetPcap requires specialized libraries for each operating system and architecture,
meaning the software would have to ship with at least six library versions to cover the
targeted operating systems.
3. Portability of Cookie Cadger would be highly limited (no ARM devices, etc).
4. jNetPcap does not provide TCP re-sequencing, meaning that any reassembly of lengthy
GET requests would require writing a custom re-sequencer. Significant progress on this
re-sequencer was made, but it was not stable enough for regular use.
In order to address these concerns, Cookie Cadger was re-architected to instead utilize the
“tshark” binary which comes as a standard part of the Wireshark suite. Wireshark (and tshark by
association) has a large team of dedicated maintainers, full cross-platform support, and a very
large user base. Most importantly, the Wireshark suite is considered to be the cornerstone of
every security auditor’s toolkit, meaning it is already widely deployed to Cookie Cadger’s target
audience.
For use with Cookie Cadger, tshark is invoked as a background process with STDOUT
redirected into Cookie Cadger. Cookie Cadger buffers this data and parses it for relevant HTTP
request information. While parsing, Cookie Cadger looks for relevant pieces of information for
analysis and storage. The table below details the types of data that tshark is instructed to provide
to the Cookie Cadger application.
22
Description
Ethernet source address MAC address of wired Ethernet sender.
Ethernet destination address MAC address of wired Ethernet receiver.
WLAN source address MAC address of 802.11 (Wi-Fi) sender.
IPv4 source address Sender’s IPv4 address.
IPv6 source address Sender’s IPv6 address.
TCP source port number TCP source port; between 0 and 65535.
TCP destination port number TCP destination port; between 0 and 65535.
UDP source port number UDP source port; between 0 and 65535.
UDP destination port number UDP destination port; between 0 and 65535.
Microsoft NetBIOS command If this value equals “0x0f”, then the sender is
announcing their presence on the network.
This is stored in order to build a more complete
profile to identify individual clients.
Microsoft NetBIOS sender name The name of the computer which sent the
NetBIOS command.
Multicast DNS sender name The name of the computer which sent a
multicast DNS request or response. Multicast
DNS is heavily utilized by Apple devices as
part of the “Bonjour” network discovery
service on both Windows and OS X.
HTTP host name The host an HTTP request is addressed to [13].
HTTP request URI The URI an HTTP request is addressed to [13].
HTTP accept types Specification of accepted media types in an
HTTP response [13].
HTTP accept encoding directives Specification of accepted content encodings in
an HTTP response [13].
HTTP user agent identifier The user agent responsible for making the
23
request. This is typically the user’s web
browser [13].
HTTP referer URL The full URL of the page responsible for
referring the user to the current page [13].
Please note that the term “referer” is the
officially-accepted spelling of this directive.
HTTP cookies Semicolon-delimited list of cookie names and
values [13].
HTTP authorization Client-specified authorization parameters.
Typically “Basic” authorization is used, in
which the user name and password are Base64
encoded, then transmitted to the server [13].
3.3 Data Acquisition Methods
Cookie Cadger supports two methods of obtaining data: live capture on a network device,
or import of an existing packet capture file. In live capture mode, the user may select a device to
capture from by selecting its name from the populated list. Once the user has pressed the button
to begin capture, tshark is invoked for capturing on the specified device, and a new dedicated
thread is spawned to handle request data. This threaded approach allows for multiple devices to
be used for simultaneous data capture and analysis, all managed from the single instance of the
application.
24
Figure 7 – Multiple capture device support
Cookie Cadger supports the import of existing packet capture files (“pcap” files) into the
application for analysis. These pcap files are most often generated by network capture software,
such as tcpdump or Wireshark. Many other third-party applications also support reading and
writing this popular file format, such as the popular Android application “Pixie Network
Monitor” [14]. Pixie is a smartphone application that is capable of capturing unencrypted Wi-Fi
traffic for later export to a pcap file. This file can later be imported to Cookie Cadger for HTTP
request analysis. This popular feature gives users flexibility in how they collect and analyze
HTTP request data.
25
Figure 8 – Import from existing capture file
3.4 Analysis of Clients, Domains, and Requests
3.4.1 Layout
For analysis of HTTP requests, Cookie Cadger features a three-column layout breaking
out all discovered clients, the domains associated with each client, and the requests associated
with each domain. Clients are organized by MAC address in alphabetical order. As Cookie
Cadger captures data, the software keeps track of multiple important pieces of information about
the client, including IP addresses, user agent names, and hostnames. This information is
26
associated with each client entry and displayed as the user hovers the mouse over an individual
entry.
Figure 9 – Client information tracking
As HTTP requests are picked up by Cookie Cadger, the software highlights the client
MAC and the domain that match the new requests. This allows an auditor to immediately see
which clients have activity on the network and which are just sitting idle. As the user hovers the
mouse cursor over an individual request, an informational display once again appears to provide
specific information about the request. This includes details of the request’s URI, the user agent
that requested the page, the page which referred this request, and the cookies transmitted to the
27
server. This cookie list will often contain a session cookie, which can be replayed to facilitate a
successful sidejacking attack. Other cookies might also be discovered which control various site
behaviors, such as language or ad preferences.
Figure 10 – Request information tracking
3.4.2 Data Export to Clipboard
Security auditors need to be able to quickly and easily copy information out of an
auditing utility and into their final report. To ensure that Cookie Cadger fits the needs of
enterprise auditing, the software has been equipped with the ability to quickly copy a selected
item to the system’s clipboard for pasting into another application. Additional options are held
in the “Edit” menu which allow the export of all requests in the current view to the clipboard.
28
Figure 11 – Exporting request data to clipboard
3.4.3 Real-time Filtering
Cookie Cadger provides real-time filtering of on-screen data in order to narrow down
fields of interest in each column. This filtering is performed as the user types and aids them in
quickly locating a particular set of clients, domains, or requests. An example of this can be seen
in the figure below.
29
Figure 12 – Real-time filtering
3.5 Request Replay into Browser Session
After selecting a request, users are provided with the option to “Load Domain Cookies”,
“Replay Request”, or “Modify & Replay Request”. All of these features allow the user to replay
a session into the Firefox browser, but each behaves in a different manner.
The “Load Domain Cookies” button loads the domain state as it most recently appeared
over the capture medium. To load any session data for the selected domain, Cookie Cadger will
30
pull the most recent GET request for a domain and replay its user agent and cookies. The referer
field is left blank, and the request URI is set to / (the root of the domain). This is the easiest way
to load a captured session into Cookie Cadger.
The “Replay Request” button replays the selected request, including the referer and
request URI. This allows Cookie Cadger to replay the request as closely as possible to the
original. In the figure below, Cookie Cadger has identified a page loaded from eBay.com which
the client is preparing to replay.
Figure 13 – Replay of an individual request
31
Upon clicking the replay button, Cookie Cadger spawns the BrowerMob intercepting
proxy in a dedicated thread. BrowserMob is an open-source proxy library for intercepting and
modifying requests and responses in transit [15]. Cookie Cadger uses BrowserMob to catch and
re-write headers as each page is requested by the browser. This allows Cookie Cadger to strip
out the browser’s own fields (such as user agent, referer, authorization) and replace them with
the spoofed values.
Once BrowserMob’s initialization has completed, Selenium WebDriver is launched.
Selenium WebDriver is a browser control framework primarily developed for browser
automation and testing [16]. Cookie Cadger utilizes Selenium WebDriver’s functionality for
navigating the Mozilla Firefox web browser to the URL specified by the user. In the figure
below, the requested page on eBay.com has been loaded into the Firefox browser instance under
the control of Cookie Cadger. This instance of Firefox now is logged in to eBay as the victim of
this session sidejacking attack.
32
Figure 14 – Successful session sidejacking of eBay account
The final method, “Modify & Replay Request”, gives users the ability to modify request
parameters before replaying them. Upon clicking this button, Cookie Cadger presents a window
to the user which allows the user to alter the URI, user agent, referer, authorization, and cookies
of a request. This method is particularly useful for modifying the user agent to be a PC-based
33
browser instead of a mobile browser, or for altering the authorization header to attempt various
usernames or passwords.
Figure 15 – Modification of a request before replay into browser
3.6 Automatic Session Detection
In addition to presenting HTTP requests in a simple, searchable manner, Cookie Cadger
also features “session detection”. Session detection works by starting a new thread for each
captured HTTP request as it is received. This thread then utilizes “plugins” to determine whether
34
or not the session matches known web services. These plugins are written in JavaScript (to
avoid the need for compiling) and are simple to create. The session detection engine locates all
plugins and passes information about the HTTP request to them. These plugins are then
executed by Java’s JavaScript execution engine. Upon finishing its execution, the plugin can
optionally return a thumbnail picture for the site, display text for the GUI, and the URI to open if
the user chooses to replay it. For an example of this, the plugin for Facebook is shown here:
importPackage(Packages.com.cookiecadger); var description; var profileImageUrl; var sessionUri; function processRequest(host, uri, userAgent, accept, cookies) { description = null; profileImageUrl = null; sessionUri = null; if((host === "www.facebook.com" || host === "facebook.com" || host === "m.facebook.com") && cookies.indexOf("c_user") != -1) { var c_userPosition = cookies.indexOf("c_user="); var facebookUserID = cookies.substring(c_userPosition + 7); if(facebookUserID.indexOf(";") != -1) { facebookUserID = facebookUserID.substring( 0, facebookUserID.indexOf(";") ); } var apiQueryResult = Packages.com.cookiecadger.Utils.readUrl( "https://graph.facebook.com/" + facebookUserID, userAgent, accept, cookies); var facebookProfile = JSON.parse(apiQueryResult); description = "<html><font size=5>Facebook</font><br>" + facebookProfile.name; profileImageUrl = "https://graph.facebook.com/" + facebookUserID + "/picture"; sessionUri = "/"; } }
35
In the example above, Cookie Cadger attempts to find a “c_user” token in cookie data for
any site which matches a Facebook hostname. This c_user value stores the Facebook user’s
unique ID, which can also be used to retrieve their profile picture. The plugin uses this
information to pass Cookie Cadger the user’s profile photo URL into the user interface.
Figure 16 – A valid Facebook session is loaded using session detection
36
If a profile image is not specified by the plugin, Cookie Cadger instead pulls an icon from
the page known as a “favicon”. The favicon is typically used by web browsers to display an
iconic representation of the page in tabs and bookmarks. Likewise, Cookie Cadger can use this
icon to represent websites supported by session detection.
Session detection can be used for not only major websites, but also major frameworks.
For example, the Drupal web framework is widely used by companies, universities, and even the
White House. Drupal’s session cookie scheme allows Cookie Cadger to detect Drupal-created
session cookies on all websites that use the framework. This is a major development over
previous session sidejacking utilities (such as Firesheep) that are only able to support specific
websites by hostname identification.
Finally, session detection has the ability to automatically load hijacked sessions into the
browser in real-time (a feature known as “demo mode”). Demo mode does not require any
operator involvement and is primarily intended for kiosk-style demonstrations of the security
problems related to session sidejacking and open Wi-Fi.
37
Figure 17 – A Drupal installation is identified using session detection
3.7 Database Storage
Cookie Cadger supports two database methods: SQLite (the default) and MySQL.
SQLite provides Cookie Cadger with a local database stored on-disk. This provides very high
performance for cataloging and accessing data inside of Cookie Cadger. Additionally, the
SQLite database (referred to in the application as a “Dataset”) can be saved or loaded into the
application from a previously-saved session. Finally, SQLite is a very popular data storage
38
method, and this allows other utilities to open and interact with Cookie Cadger datasets. Other
applications could utilize collected data for information gathering, statistical analysis, and so on.
Cookie Cadger’s second supported storage engine, MySQL provides a trade-off between
performance and portability. When appropriately configured, Cookie Cadger can save data to
either a local or remote MySQL server installation. Additionally, the software supports
concurrent read and write operations to the database by other systems running Cookie Cadger.
This means that a wide-reaching assessment can be conducted against multiple network
endpoints while data analysis occurs elsewhere. Each instance of Cookie Cadger can be set up to
check for new updates to the data from the MySQL server in order to stay in a synchronized state
with all other instances.
Figure 18 – Configuration settings for MySQL database storage
39
3.8 Headless Operation
While Cookie Cadger is primarily intended for use on systems with a graphical interface,
there are many reasons why an auditor would desire to run the software in a headless mode (that
is, without a graphical interface). For instance, the auditor might be running Cookie Cadger
from a remote shell, a dedicated security appliance, or simply desires to operate the software in a
covert fashion. For these reasons, Cookie Cadger contains the ability to run without a graphical
interface. Cookie Cadger will assess system features and drop down to headless mode if it
detects that a graphical environment is not available. Alternatively, headless mode can be
manually specified with a runtime argument.
Figure 19 – Demonstration of headless mode
An external database is required for use with headless mode. If the auditor wishes to
view captured HTTP requests they may simply open Cookie Cadger locally with its full
40
graphical interface. This interface can then be configured to use the shared database server that
the headless instance is already reporting data to. Any new data will automatically be loaded
into the graphical interface at a specified interval and immediately available for replay.
41
CHAPTER 4. FUTURE DIRECTION
After a year of development, Cookie Cadger has matured into a feature-rich suite for
auditing HTTP requests transmitted over Wi-Fi and wired Ethernet. However, further work is
needed to speed up performance, develop a more robust error handling system, and enhance
existing features. Many of these features are already underway, with planned completion by the
end of summer 2013.
As with any software which relies on a database-oriented storage model, Cookie Cadger
suffers from a few inefficient queries and overly-complex data handling processes. Large
performance gains have been realized between each release, but more work remains to ensure
that returned queries are handled in the most efficient way possible. Additionally, investigation
has begun into how Cookie Cadger could perform queries in-memory and only write to the
database instance as needed. This would increase Cookie Cadger’s performance, though more
work is needed to understand the full ramifications of such a major architectural change.
While creating Cookie Cadger, the goal was often to simply “make it work” in the
interests of time. This means that error handling and logging was largely added as an
afterthought. The addition of a robust error handling and logging system is needed in order to
42
help users troubleshoot and diagnose issues with the application. Additionally (and regretfully),
the code needs pretty significant refactor and the addition of many more comments and Javadoc
in order to reduce the amount of effort which will be required for the open-source community to
contribute to the project.
Cookie Cadger’s feature set will see some expansions in the immediate future. Support
for replaying captured sessions into the Google Chrome web browser is already in development,
and will likely be followed up with support for further database engines. The plugin architecture
will continue to grow in order to support more websites and services that do not enforce HTTPS
after a successful login.
Finally, many in the information assurance community are excited for the 1.0 release of
Cookie Cadger, along with its source code. The software’s open-source nature will ensure that
developers can contribute and grow the project for years to come, and this flexibility will only
strengthen the benefit that Cookie Cadger brings to professional security engagements.
43
CHAPTER 5. CONCLUSION
The Internet has changed substantially since the introduction of HTTP cookies by
Netscape engineers in 1994. While most websites on the Internet transmit user credentials over
SSL/TLS, many websites drop users down to HTTP-only transmissions which allow leakage of
the session cookie or other sensitive data.
Acknowledging the progress made by tools like “Ferret and Hamster” and “Firesheep”,
Cookie Cadger was built to be the first easy-to-use session sidejacking suite designed for use by
professional security auditors. Cookie Cadger has been designed to analyze 802.11 (Wi-Fi)
networks and wired Ethernet connections for unencrypted HTTP requests while maintaining full
cross-platform support – all from a single binary file.
While in development, Cookie Cadger was used to detect an issue within Google
AppEngine’s session management. Further investigation led to the identification of a bug which
facilitated a successful cookie sidejacking of a Google AppEngine session using Cookie Cadger.
Google was contacted in April 2012 and fixed the security hole in October of 2012 [17].
44
At the time of writing, Cookie Cadger has been installed on 4,144 computers since being
released publicly 182 days ago on September 30th
, 2012 – an average of nearly 23 installations a
day. On average, a new instance of Cookie Cadger is launched every 21 minutes across all three
of the originally targeted platforms:
Prevalence Operating System
78% Microsoft Windows
20.8% Apple Mac OS X
1.2% Linux (various distributions)
For the first month after its release, Cookie Cadger was “sold” at a minimum price of
$10, though purchasers could give more if they felt compelled. All proceeds went directly to
Hackers for Charity, an organization dedicated to helping African children and families in need.
A goal to raise $1,000 in the month was set – and three days later surpassed. To date, the Cookie
Cadger project has been able to raise $2,732 for Hackers for Charity.
45
BIBLIOGRAPHY
[1] J. Schwartz, "Giving the Web a Memory Cost Its Users Privacy," [Online]. Available:
http://www.nytimes.com/2001/09/04/technology/04COOK.html. [Accessed 20 April 2012].
[2] Netscape, "The SSL Protocol, Version 3.0," 3 1996. [Online]. Available:
http://web.archive.org/web/20030605082439/http://wp.netscape.com/eng/ssl3/ssl-toc.html.
[Accessed 20 2 2013].
[3] T. Dierks and C. Allen, "The TLS Protocol, Version 1.0," 1 1999. [Online]. Available:
https://www.ietf.org/rfc/rfc2246.txt. [Accessed 20 2 2013].
[4] S. Gilbertson, "HTTPS is more secure, so why isn’t the Web using it?," 20 3 2011. [Online].
Available: http://arstechnica.com/business/2011/03/https-is-more-secure-so-why-isnt-the-
web-using-it/. [Accessed 30 3 2013].
[5] Microsoft Corporation, "Handling Mixed (HTTPS/HTTPS) Content," IEInternals Blog, 22 6
2009. [Online]. Available: https://blogs.msdn.com/b/ieinternals/archive/2009/06/22/https-
mixed-content-in-ie8.aspx. [Accessed 20 2 2013].
[6] Tcpdump/Libpcap, "Manpage of TCPDUMP," 5 3 2009. [Online]. Available:
http://www.tcpdump.org/tcpdump_man.html. [Accessed 21 2 2013].
46
[7] N. Sofer, "IECookiesView," 24 3 2009. [Online]. Available:
http://www.nirsoft.net/utils/internet_explorer_cookies_view.html. [Accessed 21 2 2013].
[8] B. Krebs, "New Tool Automates Webmail Account Hijacks," 2 8 2007. [Online]. Available:
http://blog.washingtonpost.com/securityfix/2007/08/new_tool_automates_webmail_acc.html.
[Accessed 21 2 2013].
[9] G. Ou, "Hamster plus Hotspot equals Web 2.0 meltdown!," 2 8 2007. [Online]. Available:
http://www.zdnet.com/blog/ou/hamster-plus-hotspot-equals-web-2-0-meltdown/651.
[Accessed 21 2 2013].
[10] K. Murphy, "New Hacking Tools Pose Bigger Threats to Wi-Fi Users," 17 2 2011. [Online].
Available:
http://www.nytimes.com/2011/02/17/technology/personaltech/17basics.html?_r=0.
[Accessed 20 2 2013].
[11] E. Butler, "Firesheep," [Online]. Available: http://codebutler.github.com/firesheep/.
[Accessed 20 2 2013].
[12] Sly Technologies, Inc, "jNetPcap," [Online]. Available: http://jnetpcap.com/. [Accessed 22 2
2013].
[13] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach and T. Berners-Lee,
"Hypertext Transfer Protocol–HTTP/1.1," RFC 2616, 1999.
[14] 9Bit Labs LLC, "Pixie Network Monitor for Android," [Online]. Available:
http://www.9bitlabs.com/Pixie/. [Accessed 22 2 2013].
[15] Webmetrics, "BrowserMob Proxy," [Online]. Available:
47
http://opensource.webmetrics.com/browsermob-proxy/. [Accessed 15 3 2013].
[16] SeleniumHQ, "Selenium WebDriver," [Online]. Available:
http://docs.seleniumhq.org/projects/webdriver/. [Accessed 15 3 2013].
[17] Darren Pauli, SC Magazine Australia, "Google App Engine open to session jacking," 10
October 2012. [Online]. Available:
http://www.scmagazine.com.au/News/318610,65279google-app-engine-open-to-session-
jacking.aspx.
48
ACKNOWLEDGEMENTS
I would like to thank all of my friends who have helped me, supported me, and done
everything possible to make this project succeed. Thank you so very much for helping with
testing, reporting bugs, and giving feedback. Without you, this project would never have gotten
off the ground. I would especially like to extend my gratitude to Benjamin Holland and Justin
Kaufman for their contributions to the project, and to Ellen Hartstack, Max Peterson, and Curt
Putney for proofreading and editorial assistance.
Next, I would like to thank Dr. Doug Jacobson and the Information Assurance Center for
the support and guidance throughout my time at Iowa State University. I also wish to thank my
committee members for their assistance with this project and my continued academic and
professional development.
For my family – Ed, Deb, and Lindsey Sullivan: thank you so very much for your love
and unwavering support throughout this incredible journey. It has meant the world to me.
Finally, I wish to thank my fiancé, Kala Barre, who has selflessly sacrificed over and
over throughout our adventure together. For the last six years you’ve given nothing but love and
encouragement every single day, tolerating my oddities with a smile. I’m a very lucky man.