Editor’s Note: On November 1, 2012, Alex Halderman and several other experts participated in a live streaming symposium on the state of electronic voting in Election 2012: E-Voting: Risk and Opportunity (archived video now available). The event was hosted by the Center for Information Technology Policy at Princeton.
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, http://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.
Get the whole story on the DC Internet voting hack. Who is responsible, including how this could have happened when the West Virginia Internet voting system works great. Read my piece on Op Ed News. Search the question above.
WJK
On-line?
Subverting a voting system that has already been socially engineered to give you only false choices between two equivalent evils is a lot like congratulating yourself on a successful theft from the local landfill. We’re so busy keeping careful watch on the street magician’s right hand that we are ignoring the fact that the left hand has already relieved us of our wallet.
Would this attack have worked if the system were not using Microsoft Windows? “Ruby on Rails” is a type of “open source” that Microsoft people have tried to stick on Windows. Is this machine really running IIS on Windows 2008 like Netcraft thinks? If so, there are many more exploits waiting for you.
The insistence on keeping a file name extension itself is a bad habit taught by that OS, so the root cause could be described that way. A unix person, even if they wanted to keep extentions of human readability would at least have provided it themselves. GPG and free software pdf readers do not care about extensions.
Another question is if better permissions and chrooting could have helped.
Thanks for the interesting work.
Dr. Halderman, I wil contact you personally. As I see it they won’t listen to us and they will create a web based absentee voting system no matter what.. I would feel much better if rather than doing what India did is that they work with you and others by first hardening the internal system with it preferably being hosted on OpenBSD with RSBAC if they cite SeLinux as needed. After that is done they will need an external system also based on OpenBSD that logs any of shell or other injection attacks and logs them with SNORT with an IP black-listing policy. They also need multi-party electioneering officials educated and monitoring the entire process, not just some system administrators. They need to understand this will take a lot of time with successive enhancements to make it secure enough. But they are going to do it whether we like it o not.
First, kudos for the successful attack. I am surprised they had no or insufficient protection against a shell injection attack.
I think we need to stop worrying about the DMCA. What needs to be done is to allow this testing to harden these systems, IF people want to continue to investigate them. I think it needs to be done in a much less public way for the initial testing and hardening. This is probably a real eye opener for the people who created the system. They may be excellent computer scientists but those who specialize in computer security are entirely different and think much deeper and in more novel ways.
The problem is, this kind of solution for voting is shunting aside what is needed. First is multi-partsan monitoring. The second has already been mentioned which is the secrecty of the ballot. These factors (there are more) need to be spelled out first because that is what should drive the design of any system used to replace what is already there. Difficult questions need to be asked and answered. What is wrong with the current method of doing things? Usually you only fix what is broken. Internet voting seems to be breaking what is fixed. Newer does not always equate to better. I still think the fundamental flaw of this type of system is that it reduced the human monitoring element way too much.
All this needs is single quotes in (‘) instead of double quotes (“) to be used to wrap around the filename.
I am susprised that everyone is focusing on the “vote integrity” issue and ignoring the fundamental flaw of the system.
With any kind of internet voting, it is impossible to guarantee the secrecy of the vote. We cannot trust that the remote machine is safe, we cannot tell whether someone is watching over the voter’s shoulder, and the voter cannot be sure that the server is not rigged to record who casted each vote. (A paper trail with audits may guarantee vote integrity, but cannot guarantee vote secrecy.)
Even if vote secrecy is not actually violated, the mere suspicion that it *could* be violated, by the government or by some local entity (e.g. the local cable company) may be sufficient to intimidate the voters. A voting system that requires voters to trust the government is obviously not acceptable.
This may not be a big issue for overseas military voters, but it certainly excludes internet voting as a viable option for the general public.
why don’t the professor conduct the same type of investigation into the electronic machines we use today. We don’t know anything about it. It uses servers and networks etc. That will be more useful. Let us know about how secured or otherwise it is. Reveal all the hidden processes that is NOT available to voters…. yet, we want to jump all over the open source apps ..you bank over the internet don’t you …If you can do that, without any inhibitions then voting online is definitely plausible …The bottom line is they do not want it to succeed because they are scared they will loose control of the process …because they cheat !!!
They cheat alright but the incumbent power structure doesn’t need to fiddle votes to do it — they get to draw the district boundaries and collude between the two major parties to be more alike than they are different!
If you’ve followed Professor Halderman over the years, you know that he was on Ed Felten’s team that completely demolished the Diebold Accuvote electronic voting system. Masterful work there – I believe the hack required a hotel minibar key as well as a SD card.
http://www.cse.umich.edu/~jhalderm/pub/papers/ts-evt07.pdf
http://www.cse.umich.edu/~jhalderm/pub/papers/diebold-ttbr07.pdf
http://www.cse.umich.edu/~jhalderm/pub/papers/avc-evt09.pdf
http://www.cse.umich.edu/~jhalderm/pub/papers/evm-ccs10.pdf
http://www.cse.umich.edu/~jhalderm/pacman/
🙂
Gee- I thought everyone knew there is no secure method for internet voting. The only solution to the election systems crisis that has actually been demonstrated is the OVC ” Dechert Design ” system that was demo’d at Linuxworld ‘ 08.. Ballot printers with open source code- duh !! Why do we continue to spin in circles- ?? This fiasco was an embarrassment to OSDV and Kapor-
The lesson we should be taking here is that Internet voting is a really really bad idea. There are very few and very small benefits, compared with countless risks. The nature of this particular vulnerability was such that the team could well have changed all the votes and *no one would have known*. There is no way to audit this stuff, folks. If you crack the server, you can change the audit trail! Not to mention social attacks. If all else fails, pay off the sysadmin, or break into the server room.
Yes, I’m glad they tested it, but even if the test had completed without a successful attack, *that wouldn’t tell us that it was secure*. The real bad guys have more time, money, and motivation than a team of Michigan CS grad students.
The first question to ask about any voting system is: if there’s a failure or breach, can you figure out the actual results? How do you do that? In person voting, multiple checkpoints, multiple observers at each point. Computer voting is okay *if it produces a piece of paper* that the voter can verify and then has to stuff in the ballot box.
If you don’t have all those features, then you can’t know if your vote can be trusted. A completely computer-based system would be far more expensive and give you far less trust. What is the point?
Paper is a great technology! Let’s harness it!
The District of Columbia should be congratulated for running this public test. Yes THIS system failed but having others care enough to devote considerable talent towards cracking it is a positive outcome. If you keep at it, eventually a system will survive public testing. As long as the entire system is open source and can be tested by anyone, I’d feel comfortable using it. So to the D.C team that came up with this system and were willing to expose it to public testing, you did very good. Keep up the good work. Eventually you’ll have a system that you can be proud of.
It’s an interesting attack! I learned long ago that the user inputs should be validated before being acted upon. Surely it would not be so difficult to validate the filename BEFORE processing it with an unix script! If you expect ‘.pdf’ then make damn sure you receive ‘.pdf’ and not ‘.$(my unixcommend)pdf’.
bad code contaminates a good idea.
you would think some opensource net geeks would know better.
either way, internet voting(along with everything else) is the way.
Haters will hate, but the team deserves credit for patching the vulnerability so quickly:
http://github.com/trustthevote/DCdigitalVBM/commits/master
Since the software is open source and on GitHub, I look forward to reading about what other vulnerabilities you discovered, and how exactly to fix them.
John Sebes and Greg Miller have done a wonderful job in potentially leading to the continued disenfranchisement of overseas military and civilian voters. I am wondering why DC has been left holding the bag while the providers of this “brittle” system can lay low and take no heat for their gross incompetence. Sebes and Miller are arrogant and self-serving individuals who have no understanding of elections or web-based security. They managed to convince DC that their open-source approach to this type of technology was superior to all others – well we can see where that has gotten.
DC should demand their money back. And Sebes and Miller should apologize to all those overseas voters that this farce will impact into the future.
I’m pretty sure OSDV didn’t see a penny of that… that money did not go to the OSDV side of the development but for the internal infrastructure and personnel. Of course, someone that has seen the budget would have to say more. But I think there’s a blog post or two on OSDV’s blog that specify they’re uncomensated for this work.
I’m glad that a UofM team did it, but if it was that simple, were you guys the only ones working on it? Where was this public call to test it out made?
Anyway, whose idea was it to use the fight song? Cause that was the best part of the hack. 🙂
Before I start – for the people complaining about the cost: $300,000 is a small salaried software development team for one year – including the costs of administrative staff, hardware, software, planning, etc. Good programmers start at $70K each. Do the math and this was actually about right for the project. No one likes seeing those numbers in terms of government because that means tax money but it really needs to be done to get rid of our antiquated system of voting.
That’s the only positive thing I’ve got to say. Complaints follow:
1) Welcome to the government where the programmers within don’t understand simple things like scrubbing input data. The correct approach is to assume ALL input data is attempting to hack the system and scrub it! And then, when you go to use the data, scrub it again just in case you screwed up something earlier. This is secure software development 101.
2) Only allowing for three days to test a major system before going live is stupid-dumb. I’m a pretty good programmer myself but on a project that took me a year to develop, I spent another three months extensively testing the software. I was sick of it by the end but it was worth it.
3) Last, but hardly least: The choice to use Ruby on Rails as the platform is a complete FAIL. It may be fine for small applications BUT it is not up to the task of serious software deployments. We use Ruby here on occasion and it does NOT scale. A mere 10 concurrent users can bring down most simple Ruby apps. Twitter – if you need another example – throws hardware like crazy at Ruby and they still have scalability issues.
This was a vulnerability related to uploading a file. It could have happened in any framework. Twitter has consistently stated that their scaling issues were related to running a system better suited to a queue in a database based environment. This reflects nothing on Rails ability to scale. Security is hard. It takes good algorithms and smart implementations but in the end, it comes down to trial and error, like we have here.
Oh, here we go. Framework rwars time.
Compojure rawks!
Someone pass the popcorn. 🙂
Let’s work on our reading comprehension, shall we? The software was produced by a private foundation. See where it says that?
Please tilt your teabags at some other windmill.
First off, thanks for providing this great break down of your attack. I read about it a few days ago and wondered how you guys pulled it off. It’s always nice to get the details like this, allowing me to learn from the mistakes rather then just hearing a high level report about the consequences.
Is the bug that executes the unsanitized, user-supplied, filename lie in the open source trustthevote code? Or was that part of the custom bits added?
DC is doing the right thing here. Testing prior to production is the way to go.
Here’s an example of a production system that was not tested thoroughly enough. Result – massive data loss (very sensitive medical/personal information).
http://voices.washingtonpost.com/securityfix/2009/05/hackers_break_into_virginia_he.html
First, my congratulations to Alex and his team for a job well done.
Second, we should congratulate the DC Board of Elections and Ethics for putting the system out there for testing. Every other Internet voting experiment (and they need to be called “experiments” not “pilots”) has taken the blind faith of the vendor that the system was secure. While there are many reasonable critiques of how they did it (short notice, short testing time, poorly defined testing rules), we should applaud that they were open-minded enough to ask for help. That’s more than was done in Hawaii, Michigan, Arizona, or by Democrats Abroad, all of which have run small-scale elections using proprietary software without any independent verification.
Regarding the use of PDFs, there were good reasons they did that (as well as bad reasons). I encourage everyone to read the DC BoEE’s “rationale” document at http://www.dcboee.us/DVM/DCdVBM-DesignRationale-v3.pdf which explains what the considerations were (legal and technical), alternate solutions they considered, etc. It’s a well-written treatise, and while I disagree with many of their conclusions, it’s important to understand that they didn’t do this in the dark.
As for the $300K, I suspect much of that was spent in defining requirements and getting buy-in – no, it wasn’t done perfectly, but simply hiring 4 junior programmers (as someone suggested on this forum) without clearly defined requirements would lead to a system that might be more secure, but far less likely to meet real needs.
I know governement has a love for PDF, but I find it paradoxical that both Ruby and PDF upload were chosen by one group of web developers. Also Scribd recently proved that pdf is no longer necessary for the web =D.
Thank you for this very clear description of the exploit; I’m using it with a library-technology class I teach.
As for PDF, I’m not surprised (though I am dismayed) that it was chosen. An article of faith in voting is that everyone insofar possible should see exactly the same ballot. Because PDF, unlike most HTML, reproduces the printed form of a page fairly exactly, it was a logical (though likely not reasonable) choice of file format.
I agree that DC seems to have done good things here.
It didn’t work out as well as hoped for but that’s OK (sort of).
The really GREAT thing is that they had the really good sense to open it to general testing rather than, as many jurisdictions have done, doing it internally and then stonewalling complaints. I just wish that were true for all the places that have been doing the touchscreen systems.
I don’t put much faith in praising the government for not doing the wrong thing, it sets the wrong standard. Also, while at first glace it seems great that they gave indepent researches a crack at the software, it also means they they thought the software with such a simplistic security issue was ready to be tested.
For those that aren’t aware, $300k is enough to pay 4 $75k rockstar developer salaries for A YEAR to develop a web app to securely take a vote. How much could it cost to hire a “security pro” to help with the design for a week? 10k? But it wouldn’t take a pro, you can google search “how to secure a website” and hit I’m feeling lucky and I promise the page you land on will cover sanatizing user input. This wasn’t an obscure attack vector, this was a security issue that was likely covered by Ruby on Rails for dummies.
I promise you they could have offered a $50k prize to university students to develop this web app with rails, took their cutest paiges on cocaine fueled vacations, and still had a more robust, secure site, for FAR less cost to the tax payers.
p.s. Modern web frameworks like the one used make things like sql injection attacks a thing of the past, they scrub all user input based on the defined desired input, these developers simply did put forth the slightest amount of forethought or effort in security.
p.p.s. cast a vote via file upload? seriously?
As someone who pays programmers a salary, I know what it costs to pay “rockstar developer” salaries, and $75K per year doesn’t come close. I start someone with a masters degree in the mid-sixties; $75K is what I pay a competent programmer with a masters (or equivalent) and less than five years of experience. I have had “rockstar developers” on my payroll; keeping them around requires salaries upwards of $100K. In my shop, $120K would be a more likely base.
But this ignores fringe benefits, which run at about 30%, and overhead costs, i.e., my costs in providing space, heat, light, etc., which runs upwards of 50% of loaded salary. Together, these additional costs more than double the cost of salary alone. A better estimate of the cost of a “rockstar developer” is more like $250 per year. And this does not include computing infrastructure costs, like workstations and other project-related gear.
So I wouldn’t put much stock in anon’s assertions about the cost or value of things.
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
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.
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… http://lmgtfy.com/?q=how+to+secure+a+website&l=1
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.
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
@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.
they paid $300,000 for a webapp that doesn’t scrub its input?
Yes, they did. This isn’t a surprise.
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?
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.
…our public elections are not “Dancing With The Stars.”
Thank you for your great work and for sharing your important discoveries.
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.
Thanks from a current student and long time voter. Integrity in journalism and integrity in voting – both very important.
for your excellent work and that of your team. Great summary; important findings.