Penetration Test Report (University of Michigan Ann Arbor): dcvoting fc12

In Proc.16th Conference on Financial Cryptography & Data Security, Feb. 2012
Attacking the Washington, D.C.
Internet Voting System
Scott Wolchok, Eric Wustrow, Dawn Isabel, and J. Alex Halderman
The University of Michigan, Ann Arbor
{swolchok,ewust,dki,jhalderm}@umich.edu
Abstract. In2010,Washington,D.C.developedanInternetvotingpilot
project that was intended to allow overseas absentee voters to cast their
ballots using a website. Prior to deploying the system in the general
election, the District held a unique public trial: a mock election during
which anyone was invited to test the system or attempt to compromise
its security. This paper describes our experience participating in this
trial. Within 48 hours of the system going live, we had gained near-
completecontroloftheelectionserver.Wesuccessfullychangedeveryvote
and revealed almost every secret ballot. Election officials did not detect
our intrusion for nearly two business days—and might have remained
unawareforfarlongerhadwenotdeliberatelyleftaprominentclue.This
case study—the first (to our knowledge) to analyze the security of a
governmentInternetvotingsystemfromtheperspectiveofanattackerin
a realistic pre-election deployment—attempts to illuminate the practical
challenges of securing online voting as practiced today by a growing
number of jurisdictions.
Keywords: Internet voting, e-voting, penetration testing, case studies
1 Introduction
Conducting elections for public office over the Internet raises grave security
risks. A web-based voting system needs to maintain both the integrity of the
election result and the secrecy of voters’ choices, it must remain available and
uncompromised on an open network, and it has to serve voters connecting from
untrusted clients. Many security researchers have cataloged threats to Internet
voting (e.g. [11,15]), even as others have proposed systems and protocols that
may be steps to solutions someday (e.g. [6,12]); meanwhile, a growing number
of states and countries have been charging ahead with systems to collect votes
online. Estonia [1] and Switzerland [2] have already adopted online voting for
national elections. As of 2010, 19 U.S. states employed some form of Internet
voting [5], and at least 12 more were reportedly considering adopting it [4].
Among the jurisdictions considering Internet voting, one of the most enthusi-
astic proponents was the District of Columbia. In 2010, the Washington, D.C.
Board of Elections and Ethics (BOEE) embarked on a Federally-funded pilot
project that sought to allow overseas voters registered in the District to vote
2 Scott Wolchok et al.
over the web starting with the November 2010 general election [16]. Though the
D.C. system, officially known as the “D.C. Digital Vote-by-Mail Service,” was
technologicallysimilartoparalleleffortsinotherstates,BOEEofficialsadopteda
unique and laudable level of transparency. The system was developed as an open
source project, in partnership with the nonprofit Open Source Digital Voting
(OSDV) Foundation [3]. Most significantly, prior to collecting real votes with the
system, the District chose to operate a mock election and allow members of the
public to test its functionality and security.
Weparticipatedinthistest,whichranforfourdaysinSeptemberandOctober
2010. Our objective was to approach the system as real attackers would: starting
from publicly available information, we looked for weaknesses that would allow
us to seize control, unmask secret ballots, and alter the outcome of the mock
election. Our simulated attack succeeded at each of these goals and prompted
the D.C. BOEE to discontinue its plans to deploy digital ballot return in the
November election.
In this paper, we provide a case study of the security of an Internet voting
system that, absent our participation, might have been deployed in real elections.
Though some prior investigations have analyzed the security of proposed Internet
voting systems by reviewing their designs or source code, this is the first instance
of which we are aware where researchers have been permitted to attempt attacks
on such a system in a realistic deployment intended for use in a general election.
We hope our experiences with the D.C. system will aid future research on
secureInternetvoting.Inparticular,weaddressseverallittle-understoodpractical
aspects of the problem, including the exploitability of implementation errors in
carefully developed systems and the ability of election officials to detect, respond,
and recover from attacks. Our successful penetration supports the widely held
view among security researchers that web-based electronic voting faces high risks
ofvulnerability,anditcautionsagainstthepositionofmanyvendorsandelection
officials who claim that the technology can readily be made safe.
The remainder of this paper is organized as follows: Section 2 introduces the
architecture and user interface of the Digital Vote-By-Mail System. In Section 3,
wedescribehowwefoundandexploitedvulnerabilitiesinthewebapplicationsoft-
ware to compromise the mock election. Section 4 describes further vulnerabilities
thatwefoundandexploitedinlow-levelnetworkcomponents.Section5discusses
implicationsof ourcasestudyforotherInternet voting systemsandfuture public
trials. We survey related work in Section 6 and conclude in Section 7.
2 Background: The D.C. Digital Vote-By-Mail System
Architecture The Digital Vote-by-Mail (DVBM) system is built around an open-
source web application1 developed in partnership with the D.C. BOEE by the
OSDV Foundation’s TrustTheVote project2. The software uses the popular Ruby
on Rails framework and is hosted on top of the Apache web server and the
1 http://github.com/trustthevote/DCdigitalVBM/
2 http://trustthevote.org
Attacking the Washington, D.C. Internet Voting System 3
Public Network Allowed TCP ports : 80 and 443 Allowed TCP port : 80
digital-vbm.dc.gov
Firewall and Web Server Firewall Application Server Database Server
Intrusion Detection
Fig.1: Network architecture—The front-end web server receives HTTPS
requests from users and reverse-proxies them to the application server, which
hoststheDVBMelectionsoftwareandstoresbothblankandcompletedballots.A
MySQLdatabaseserverstoresvotercredentialsandtracksvotedballots.Multiple
firewallsreducetheattacksurfaceandcomplicateattacksbydisallowingoutbound
TCPconnections.Theintrusiondetectionsysteminfrontofthewebserverproved
ineffective, as it was unable to decrypt the HTTPS connections that carried our
exploit. (Adapted from http://www.dcboee.us/DVM/Visio-BOEE.pdf.)
MySQL relational database. Global election state (such as registered voters’
names, addresses, hashed credentials, and precinct-ballot mappings, as well as
which voters have voted) is stored in the MySQL database. Voted ballots are
encrypted and stored in the filesystem. User session state, including the user ID
and whether the ballot being cast is digital or physical, is stored in an encrypted
session cookie on the user’s browser.
Electronic ballots are served as PDF files which voters fill out using a PDF
reader and upload back to the server. To safeguard ballot secrecy, the server
encrypts completed ballots with a public key whose corresponding private key is
held offline by voting officials. Encrypted ballots are stored on the server until
after the election, when officials transfer them to a non-networked computer (the
“crypto workstation”), decrypt them using the private key, and print them for
counting alongside mail-in absentee ballots.
Figure 1 shows the network architecture deployed for the mock election.
HTTPS web requests are interpreted by the web server over TCP port 443.
The web server then performs the HTTP request on the user’s behalf to the
application server, which runs the DVBM application software. The web server,
applicationserver,andaMySQLdatabaseserverallrunLinux.Firewallsprevent
outbound connections from the web and application servers. Since the web server
andapplicationserverrunonseparatemachines