Professional Documents
Culture Documents
by
Matthew Sullivan
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 users 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 crossplatform, 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
1.2.2
1.2.3
1.2.4
1.3
Outline .............................................................................................................................. 7
2.2
2.3
Firesheep ........................................................................................................................ 15
iv
3.1
3.2
3.3
3.4
3.4.1
Layout ..................................................................................................................... 25
3.4.2
3.4.3
3.5
3.6
3.7
3.8
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
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 users 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.
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].
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
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.
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.
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
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 Cadgers development before moving into a detailed walkthrough of the softwares features. Chapter four will cover future directions for the software and
the vision for its continued development, followed by a brief conclusion.
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-themiddle 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 Centers 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.
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:
SESS3881200b366096014d6fbafc8838a890=s9amjqt3s0mc3a3d48sj8nsvp0
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 attackers browser of
choice. The attacker would begin by loading the Information Assurance Centers website in the
browser. Note that the user is not logged in (black admin bar is not present).
12
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
After modifying the browsers cookie data to reflect the cookie captured by tcpdump, the
attacker loads the browser again and navigates to the targeted website.
14
On this visit the attackers 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
In Grahams 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 victims
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 users 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 users name. Firesheep would then
instruct Firefox to purge all existing cookies and load the victims cookies instead. Finally,
Firesheep would request the page.
Facebooks 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
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 Firesheeps 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
Cookie Cadgers 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.
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.
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 auditors toolkit, meaning it is already widely deployed to Cookie Cadgers 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
23
request. This is typically the users web
browser [13].
HTTP referer URL
HTTP cookies
HTTP authorization
24
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
26
associated with each client entry and displayed as the user hovers the mouse over an individual
entry.
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 requests 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.
28
29
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.
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 browsers own fields (such as user agent, referer, authorization) and replace them with
the spoofed values.
32
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.
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 Javas 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
profileImageUrl
sessionUri = "/";
}
}
= "<html><font size=5>Facebook</font><br>" +
facebookProfile.name;
= "https://graph.facebook.com/" + facebookUserID +
"/picture";
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 users
unique ID, which can also be used to retrieve their profile picture. The plugin uses this
information to pass Cookie Cadger the users profile photo URL into the user interface.
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. Drupals 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
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 Cadgers 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.
39
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
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 Cadgers 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 Cadgers 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 softwares 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
AppEngines 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%
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]
[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 isnt the Web using it?," 20 3 2011. [Online].
Available: http://arstechnica.com/business/2011/03/https-is-more-secure-so-why-isnt-theweb-using-it/. [Accessed 30 3 2013].
[5]
[6]
46
[7]
[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]
[12]
[13]
[14]
9Bit Labs LLC, "Pixie Network Monitor for Android," [Online]. Available:
http://www.9bitlabs.com/Pixie/. [Accessed 22 2 2013].
[15]
47
[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-sessionjacking.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 youve given nothing but love and
encouragement every single day, tolerating my oddities with a smile. Im a very lucky man.