Hacking the D.C. Internet Voting Pilot
The current U.S. e-voting system is a patchwork of locally implemented technologies and procedures — with varying degrees of reliability, usability, and security. Different groups have advocated for improved systems, better standards, and new approaches like internet-based voting. Panelists will discuss these issues and more, with a keynote by Professor Ron Rivest, one of the pioneers of modern cryptography.
[Update (6/2012): We've published a detailed technical paper about the D.C. hack.]
The District of Columbia is conducting a pilot project to allow overseas and military voters to download and return absentee ballots over the Internet. Before opening the system to real voters, D.C. has been holding a test period in which they’ve invited the public to evaluate the system’s security and usability.
This is exactly the kind of open, public testing that many of us in the e-voting security community — including me — have been encouraging vendors and municipalities to conduct. So I was glad to participate, even though the test was launched with only three days’ notice. I assembled a team from the University of Michigan, including my PhD students, Eric Wustrow and Scott Wolchok, and Dawn Isabel, a member of the University of Michigan technical staff.
Within 36 hours of the system going live, our team had found and exploited a vulnerability that gave us almost total control of the server software, including the ability to change votes and reveal voters’ secret ballots. In this post, I’ll describe what we did, how we did it, and what it means for Internet voting.
D.C.’s pilot system
The D.C. system is built around an open source server-side application developed in partnership with the TrustTheVote project. Under the hood, it looks like a typical web application. It’s written using the popular Ruby on Rails framework and runs on top of the Apache web server and MySQL database.
Absentee overseas voters receive a physical letter in the mail instructing them to visit a D.C. web site, www.dcboee.us/DVM/, and log in with a unique 16-character PIN. The system gives voters two options: they can download a PDF ballot and return it by mail, or they can download a PDF ballot, fill it out electronically, and then upload the completed ballot as a PDF file to the server. The server encrypts uploaded ballots and saves them in encrypted form, and, after the election, officials transfer them to a non-networked PC, where they decrypt and print them. The printed ballots are counted using the same procedures used for mail-in paper ballots.
A small vulnerability, big consequences
We found a vulnerability in the way the system processes uploaded ballots. We confirmed the problem using our own test installation of the web application, and found that we could gain the same access privileges as the server application program itself, including read and write access to the encrypted ballots and database.
The problem, which geeks classify as a “shell-injection vulnerability,” has to do with the ballot upload procedure. When a voter follows the instructions and uploads a completed ballot as a PDF file, the server saves it as a temporary file and encrypts it using a command-line tool called GnuPG. Internally, the server executes the command gpg with the name of this temporary file as a parameter: gpg […] /tmp/stream,28957,0.pdf.
We realized that although the server replaces the filename with an automatically generated name (“stream,28957,0” in this example), it keeps whatever file extension the voter provided. Instead of a file ending in “.pdf,” we could upload a file with a name that ended in almost any string we wanted, and this string would become part of the command the server executed. By formatting the string in a particular way, we could cause the server to execute commands on our behalf. For example, the filename “ballot.$(sleep 10)pdf” would cause the server to pause for ten seconds (executing the “sleep 10” command) before responding. In effect, this vulnerability allowed us to remotely log in to the server as a privileged user.
Our demonstration attacks
D.C. launched the public testbed server on Tuesday, September 28. On Wednesday afternoon, we began to exploit the problem we found to demonstrate a number of attacks:
- We collected crucial secret data stored on the server, including the database username and password as well as the public key used to encrypt the ballots.
- We modified all the ballots that had already been cast to contain write-in votes for candidates we selected. (Although the system encrypts voted ballots, we simply discarded the encrypted files and replaced them with different ones that we encrypted using the same key.) We also rigged the system to replace future votes in the same way.
- We installed a back door that let us view any ballots that voters cast after our attack. This modification recorded the votes, in unencrypted form, together with the names of the voters who cast them, violating ballot secrecy.
- To show that we had control of the server, we left a “calling card” on the system’s confirmation screen, which voters see after voting. After 15 seconds, the page plays the University of Michigan fight song. Here’s a demonstration.
Stealthiness wasn’t our main objective, and our demonstration had a much greater footprint inside the system than a real attack would need. Nevertheless, we did not immediately announce what we had done, because we wanted to give the administrators an opportunity to exercise their intrusion detection and recovery processes — an essential part of any online voting system. Our attack remained active for two business days, until Friday afternoon, when D.C. officials took down the testbed server after several testers pointed out the fight song.
Based on this experience and other results from the public tests, the D.C. Board of Elections and Ethics has announced that they will not proceed with a live deployment of electronic ballot return at this time, though they plan to continue to develop the system. Voters will still be able to download and print ballots to return by mail, which seems a lot less risky.
D.C. officials brought the testbed server back up today (Tuesday) with the electronic ballot return mechanism disabled. The public test period will continue until Friday, October 8.
What this means for Internet voting
The specific vulnerability that we exploited is simple to fix, but it will be vastly more difficult to make the system secure. We’ve found a number of other problems in the system, and everything we’ve seen suggests that the design is brittle: one small mistake can completely compromise its security. I described above how a small error in file-extension handling left the system open to exploitation. If this particular problem had not existed, I’m confident that we would have found another way to attack the system.
None of this will come as a surprise to Internet security experts, who are familiar with the many kinds of attacks that major web sites suffer from on a daily basis. It may someday be possible to build a secure method for submitting ballots over the Internet, but in the meantime, such systems should be presumed to be vulnerable based on the limitations of today’s security technology.
We plan to write more about the problems we found and their implications for Internet voting in a forthcoming paper.
—
Professor J. Alex Halderman is a computer scientist at the University of Michigan.
Comments
for your excellent work and that of your team. Great summary; important findings.
Thanks from a current student and long time voter. Integrity in journalism and integrity in voting – both very important.
Great job!
I just hope that other jurisdictions contemplating Internet voting are paying attention.
The very least they should do is conduct a trial that is more open than this one was, with more time and more transparency and funding for some skilled red teams.
And of course securing the server is just one critical task, the easiest. Attacking client machines (many of which are already infected) and Denial of Service attacks are just about always feasible.
Thanks so much for conducting this test and showing how easy it is to hack into this voting system. I only hope this same kind of test is doe for all these types of voting systems in the future.
…our public elections are not “Dancing With The Stars.”
Thank you for your great work and for sharing your important discoveries.
Since you circumvented encryption, are your activities (as much for the public good and well intentioned that they were) illegal under the DMCA?
I think what you did was great, just curious about how repressive laws like the DMCA affect this sort of activity in the public good.
They didn’t decrypt anything, just reencrypted different ballots and wrote over the originals, so this isn’t circumvention.
You’re talking about people who, in the case of an actual election, would be intent on breaking the law by interfering with the election – an act already against the law. Breaking another law along the way would not be much of a speed bump.
Were the ballots copyrighted? If not, AFAIK the DMCA does not apply at all.
They are copyrighted the minute they are created.
Ballots usually aren’t a copyrightable expression, so it’s unlikely that they are “works protected by this title” and that’s an important phrase in DMCA.
Also, when the election officials invited the public to evaluate the system’s security and usability (it depends on how they worded it) it could be construed as authorization, and most of DMCA’s prohibitions come down to doing things without authorization from the copyright holder. (And if the ballots were copyrighted (which is quite a stretch), then the PDFs that the voters send, would be derived works of the PDFs that the government sent them, and that triggers all kinds of crazy thought experiments.)
So anyway, the specific act of cracking the system probably isn’t covered. Writing the scripts that do it, though, might trip on the ludicrous 1201 (b)(1). They wrote (manufactured) a script (component) which tries uploading files with funny names, and such a script could conceivably be used to perform a DMCA violation. Obviously the script isn’t intended for that, but 1201(b)(1)(B) could apply anyway. If they didn’t attack the election for “commercially significant purpose,” then their own project doesn’t serve as an example for how their script doesn’t have “commercially significant purpose other than” circumventing.
DMCA’s anti-trafficking provision creates a theoretical risk for all sorts of projects that most people would never guess it applies to. OTOH the more often it gets used for such abusive purposes, the more risk that it’ll get struck down, so I think DMCA-proponents are reluctant to go all-out in enforcing it. That, BTW, is one of the reasons that I think DMCA-haters should use DRM and DMCA — in certain creatively perverted ways.
To be copyrightable subject matter, ballots would have to be published, i.e. made available to the public by an author, whether free of cost or not. Ballots are inherently secret in content and authorship — hence never copyrightable.
Copyright is obtained the moment the work is put into tangible form (whatever that means here, but let’s assume it means saving the completed pdf as a file, and ignore the question of whether the voter’s contribution is copyrightable – the raw ballot probably is, and distribution to voters would seem to qualify as publication). If I steal your unpublished manuscript and publish it (or a derivative), that seems pretty clearly to be infringement.
There is a good chance (although this is not legal advice and I have not actually seen any facts) that a public invitation to hack is going to moot any issue of criminal intent, indeed it will likely be deemed a license to do exactly what was done in accordance with the express terms of the “license” and thus not violate DMCA.
You have done a good job of finding a flaw in a brittle implementation of the voting software. A more fundamental issue with an Internet voting setup, however, is that it the public needs to be able to track their votes to election results. If voting is anonymous, this is not easily implemented. A backup paper trail where the voting computer counts but also prints out your vote and you toss it into a box creates a way to verify a local in the flesh voting computer’s results. But this is less feasible in remote elections. Have you considered this more fundamental issue?
they paid $300,000 for a webapp that doesn’t scrub its input?
Yes, they did. This isn’t a surprise.
@Anonymous on October 6th, 2010 at 1:36 am:
While I’m not familiar with the specifics of the Digital Millenium Copyright Act (not being a national of the USA), any provisions related to the prohibition of circumvention of copyright (or rather copy-control) mechanisms seem irrelevant to the use (or lack of use) of encryption for the purpose of secrecy in general (including ballot secrecy).
Besides, in what way did the team “circumvent” encryption? They circumvented an access control mechanism (the shell injection) which didn’t employ encryption. Instead, they used encryption for very much the same purpose as the intended one, to send in ballots in a secure fashion, albeit forged ballots.
And, as this was a pilot test set up for the very purpose of evaluating the usefulness of the system, including its security, one would assume that the researchers had permission to try these tricks. In an actual voting situation, deliberate attempts to gain control over the voting system or to manipulate the votes being sent in by other voters could have other legal ramifications, such as investigations for voting fraud or computer intrusion (depending on the laws in force in your local jurisdiction). It would seem pretty nonsensical to deal with voting irregularities as a case of copyright infringement, though I can understand your general concerns about applying the DMCA in cases where it really doesn’t belong.
If you read the DMCA carefully enough, I guess you can find wordings which seem to outlaw “circumventing” a protection mechanism you have devised yourself to protect your own works, even merely to test it. If so, then you hardly need an electronic voting pilot to demonstrate that the law can be abused against pretty much anyone.
They did not circumvent an access control that controls access to a copyrighted work. seriously, there is just no wat the DMCA applies here.
HP tried to sue Snosoft using that same logic… it failed miserably.
Windows has the same line of problems.
And for proof look at other voting system that WERE used in Florida.
The problem is those responsible for delivery were stupid, and lacked hard core security knowledge (at Uni, the acceptable level is somewhat higher) .
And we will keep on having these problems when whatever OS or app 2nd guesses the data and decides ‘I know that- I’ll be good and execute it’ instead of treating it as a string
My real issue with this is that they spent $300,000 of federal grant money (taxes) to deliver a web app that not only used possibly the worst method of data entry conceivable [FILE UPLOAD? PDF? SERIOUSLY?] but didn’t even make the most basic of checks against user input? It directly ran user inputed text on a command line?
Did they pay a highschool CS student $5/hour to code this while blowing the other $290,000 on cocaine and hookers? I hope so, because if they paid anyone an actual salary for this kind of shody work, they should fire the staff that hired them.
Have these people not been on the internet in this century? The internet is secure enough for banks to trust, with the proper security measures in place. Uploading a pdf? Give me a break.
I can’t run a lucky google search for how to secure a website, without getting a page that tells me to verify user input… lmgtfy.com/?q=how+to+secure+a+website&l=1
Seems like PDF uploads are a bad idea too. Adobe has not been very proactive in securing their data formats. Recently disclosed PDF vulnerabilities could allow a hacker to take control of any machine that reads the PDF file, which could include machines used for recounts.
such a payload laden PDF file won’t get executed on the webserver (it’s only running through gpg) but on the central PC which is intentionally not connected to the Internet for security reasons.
As it’s not connected, it’s for sure not undergoing close inspection.
So that PC decrypts the files and prints the PDF.
This means that either the PDF rendering or the printing user can be attacked. And this user prints *all* submitted ballots. So you can print doubles, or change votes or do whatever you want during printing. You just need to get your vote-pdf to the top of the line (e.g. vote as fast as the server goes online) to affect as many as possible ballots.
The DC voting folks did the right thing – they let the public test the system for them. That’s a very, very positive thing. All of us who were schooled in software engineering and cut our teeth on Brook’s Laws can never forget that rigorous, almost overwhelming testing is the only way to truly prove a software system.
For those who aren’t aware, $300K isn’t that much to spend on a custom software application, particularly in the national Capital area. We’re a high cost-of-living area. Besides, how was the DC project management team supposed to evaluate what they got? Easy – let the public attack it. The fact that this was bad news for them (simple test failure) is good news for the elective process and for DC voters.
Bottom line for me: the DC officials tried something aggressive and new, and even though the results were not what was desired, they did things the right way and thus there was no ballot compromise. This the great news! They didn’t have to let the world help them. They took the risk, and now they know that their system is unsafe.
P.S. Anyone can get caught by a shell or SQL injection “whoops.” Sadly, the design team missed this one. A good security pro should have caught that one. All user input should be tightly controlled to a specific range of characters. In the *nix world, the “bad” characters are known and easily identified.
I’m sorry Reverend Baker, but you are missing the point …
The DC voting folks did the right thing – they let the public test the system for them. That’s a very, very positive thing. All of us who were schooled in software engineering and cut our teeth on Brook’s Laws can never forget that rigorous, almost overwhelming testing is the only way to truly prove a software system.
Testing by the public is only good when you actually receive results from the testers. Uncontrolled testing by an unknown number of people with no testing parameters and no assurance of notification can hardly be considered a good thing. I would like to see the servers undergo forensic analysis to determine if they had been compromised by attackers outside the US. The good thing that came from this is that this system was compromised by white hats before it went into production.
The other good thing that came of this is that the public is now aware that the District of Columbia Board of Elections and Ethics (DC BOEE) was moving to put into production a voting system that either did not undergo any code review or security penetration testing or was performed by engineers that are not qualified to have performed the tests. The voters in DC should be asking the DC BOEE a lot of hard questions.
I think you got your references confused. Brooks’ Law has to do with adding manpower to a project : “Adding manpower to a late software project makes it later.”
For those who aren’t aware, $300K isn’t that much to spend on a custom software application, particularly in the national Capital area. We’re a high cost-of-living area. Besides, how was the DC project management team supposed to evaluate what they got? Easy – let the public attack it. The fact that this was bad news for them (simple test failure) is good news for the elective process and for DC voters.
Location and cost of living is not relevant in this case as the code was written by Trust The Vote and their contributors are scattered across the country.
As for the cost, you are correct, but not for the right reason. $300K is not nearly enough to spend on insuring that voting is protected. Voting is the cornerstone upon which all of the freedoms and rights that we have in this country are founded upon and is the single most important thing in insuring that we continue to have them.
You ask how the DC BOEE was supposed to evaluate the software? DC BOEE is surrounded by organizations that they could have turned to for guidance; NSA, FBI, CIA, NIST, DHS, etc.
Simple test failure? I’m afraid that is being over generous. This was the result of grossly insecure code, and this is not good news for DC voters. It shows them that the DC BOEE appears to not understand what needs to be done to provide a secure and confidential online voting system.
Would you be comfortable with your bank making these types of mistakes?
Bottom line for me: the DC officials tried something aggressive and new, and even though the results were not what was desired, they did things the right way and thus there was no ballot compromise. This the great news! They didn’t have to let the world help them. They took the risk, and now they know that their system is unsafe.
This is not great news. Even after the University of Michigan team added code to have their fight song played, after each cast ballot, the the system administrators and the software developers had no clue that they had been compromised. They did not realize that valid cast ballots had been replaced with ballots written by the U of M team. They did not detect the compromise, it had to be reported to them by people that were casting ballots.
Those wishing to manipulate voting will not make their presence known, and I would be willing to bet that at least half a dozen foreign countries are cursing their bad luck .
The discovery of the vulnerabilities in the DC online voting system was only made because Professor Halderman thought it would be something interesting to test. This discovery was the result of his whim and not from a control, protocol, or procedure. I am extremely thankful that Professor Halderman made this decision and for the exemplary work of his students.
The DC BOEE should be commended for attempting to save tax payer money by turning to an open source solution, but they should take a hard look at the potential impacts of their mistakes.
P.S. Anyone can get caught by a shell or SQL injection “whoops.” Sadly, the design team missed this one. A good security pro should have caught that one. All user input should be tightly controlled to a specific range of characters. In the *nix world, the “bad” characters are known and easily identified.
I disagree, only careless developers write code that is vulnerable to known attack vectors. What you deem a “whoops” is the result of Trust The Vote not performing data input verification/validation checks, code review, or security testing. I see this as failures in even the most basic IT and IT Security practices.
Anon,
I don’t know what you do or who you work for but but after more than 30 year in IT, my experience is that secure coding wasn’t and still isn’t IT’s strong suit. (Patch Tuesday anyone?) So while you accuse the Rev of missing the point, I think you overlook the state of the industry and value of this test. Realistically, how many applications get even one round of sanctioned hacking before release? This represents the exception to the rule and is a giant step torward more secure applications.
While you indicate that “Testing by the public is only good when you actually receive results from the testers. Uncontrolled testing by an unknown number of people with no testing parameters and no assurance of notification can hardly be considered a good thing. ” An accessible internet app is by definition ‘in the wild’ and we have no control over day to day hack attacks. Since the malicious hacker isn’t going to announce his presence or methods this in some ways is representative of the real world Given that, you are correct in indicating that a forensic analysis should be done – the developers need to see what else went on.
As far as cost, spending anything on iternet voting is spending too much. The internet is insecure – a secure internet is a contradiction in terms. While some sites are more or less ‘secure’ than others, the bottom lines is that security can be and will be breached.
Electronic/Internet fraud can be difficult to track and can orriginate from many fronts. A paper ballot on there other hand is less exposed to points of unproscutable fraud and doesn’t require high tech to verify counts. I’ll take a paper ballot any day.
jh