02-09-2013, 04:49 PM
Attacking the Washington, D.C. Internet Voting System
Attacking the Washington.pdf (Size: 2.15 MB / Downloads: 18)
Abstract
In 2010, Washington, D.C. developed an Internet voting pilot
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-
complete control of the election server. We successfully changed every vote
and revealed almost every secret ballot. Election officials did not detect
our intrusion for nearly two business days — and might have remained
unaware for far longer had we not deliberately left a prominent clue. This
case study — the first (to our knowledge) to analyze the security of a
government Internet voting system from the perspective of an attacker in
a realistic pre-election deployment — attempts to illuminate the practical
challenges of securing online voting as practiced today by a growing
number of jurisdictions.
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].
Attacking the Web Application
In this section, we describe vulnerabilities we discovered and exploited in the
DVBM server application. Our search for vulnerabilities was primarily conducted
by manual inspection of the web application’s source code, guided by a focus
on the application’s attack surface. In particular, we concentrated on voter
login, ballot upload and handling, database communication, and other network
activity. The fact that the application was open source expedited our search, but
motivated attackers could have found vulnerabilities without the source code
using alternative methods. For example, one might attack voter login fields, ballot
contents, ballot filenames, or session cookies, by either fuzzing or more direct
code injection attacks such as embedding snippets of SQL, shell commands, and
popular scripting languages with detectable side effects.
Attacking the Network Infrastructure
In addition to the web application server, we were also able to compromise
network infrastructure on the pilot network. This attack was independent from
our web application compromise, yet it still had serious ramifications for the real
election and showed a second potential path into the system.
Infiltrating the terminal server
The Digi Passport 8 terminal server provides an HTTP-based administrative
interface. We were able to gain access using the default root password (dbps)
obtained from an online copy of the user manual. We found that the terminal
server was connected to four enterprise-class Cisco switches (which we surmised
corresponded to the switches shown on the network diagram provided by the
BOEE) and provided access to the switches’ serial console configuration interfaces
via telnet.
We hid our presence in the terminal server using a custom JavaScript rootkit,
which we installed over an SSH session (the same account names and passwords
used in the web interface were accepted for SSH). The rootkit concealed an
additional account with administrator privileges, “dev,” which we planned to use
in case our attack was discovered and the passwords changed. We also used our
SSH access to download the terminal server’s /etc/shadow and /etc/passwd files
for cracking using the “John the Ripper” password cracker6 . After about 3.5 hours
using the cracker’s default settings, we recovered the secondary administrator
password cisco123 from a salted MD5 hash.
Network webcams
We found a pair of webcams on the DVBM network — both publicly accessible
without any password — that showed views of the server room that housed the
pilot. As shown in Figure 4, one camera pointed at the entrance to the room, and
we were able to observe several people enter and leave, including a security guard,
several officials, and IT staff new hardware. The second camera was directed at
a rack of servers.
These webcams may have been intended to increase security by allowing
remote surveillance of the server room, but in practice, since they were unsecured,
they had the potential to leak information that would be extremely useful
to attackers. Malicious intruders viewing the cameras could learn which server
architectures were deployed, identify individuals with access to the facility in order
to mount social engineering attacks, and learn the pattern of security patrols in
the server room. We used them to gauge whether the network administrators had
discovered our attacks — when they did, their body language became noticeably
more agitated.