Hacking the D.C. Internet Voting Pilot
freedom-to-tinker.com
freedom-to-tinker.com
Why is it even necessary to upload a PDF file? Wouldn't an https: form be much better? Not to mention, the latter wouldn't get stored on the local filesystem or browser cache.
Are e-voting systems (including Diebold terminals) flawed by nature because they are built by non-techie organizations?
Major credit to the administration in this case for encouraging a public pilot/evaluation period.
The major benefit of financial systems is that you can keep detailed logs and then audit them after-the-fact to figure out exactly what happened that is a problem. By the nature of secret ballots you can't have detailed logs for auditing, so the best you can hope for is printing something out on paper for the voter to verify.
Even if you have a paper ballot printed out you have the issue of most people not bothering to read what's printed on it (which, given the number of people on a US election ballot, I don't blame them for). You also have the issue of how to handle the case where the voter either made a mistake or there was a computer error and they need to change their vote from what is on their paper ballot. All of these issues can be solved, but there are a lot of them and each one you have to account for makes the human and computer protocols for voting more complicated, which is a serious issue.
Here's a good article on it from Bruce Schneier: http://www.schneier.com/blog/archives/2004/10/getting_out_th...
The main thing he recommends are:
- Open Source Code
- Making voting rules uniform
- Paper ballots printed out which are used for recounts
- Simplify the interfaces, registration process, etc.
This sort of example gets thrown around a lot and it's totally bogus. Banks are solving a much easier problem. To keep track of all the money they just need to make sure that every dollar is always tied to an account. Every transaction is logged.
A key requirement of a voting system is that it must be impossible to tie a vote to a person. This complicates things by at least an order of magnitude.
[1] You must be able to prove that everyone has voted because those who haven't receive a fine. You must not be able to tie a vote to the person who cast it because if that can be done it could lead to serious consequences for voters.
loewenskind, can you provide links to more information?
In any case, at present it's up against something thrown together with Ruby on rails.
Front-end: "vote counted!"
Back-end: vote redirected to /dev/null!
It's not immediately obvious to me how to make such a system transparent enough to convince the losers that they lost honestly. Cryptographic schemes may be able to solve it, but I think it's an open question whether they'll be convincing and secure in practice.
You can delete/alter the records! You can make fake records! You can record future activity without being noticed!
Of course for most of us here reading it, we already knew that as soon as you said "shell injection." They left something unvalidated, and you got shell access. Don't get me wrong, that's a huge problem. It's also a tiny fix. Your job isn't over. I want to know, say they fix that hole, which should take all of two seconds. How secure is the system now?
You say that you're "confident" you could have found another attack— do you mean you're sure there's another way to run unescaped shell commands? You're guessing. There's no evidence that there is unless you found one. You just don't know.
A much, much bigger problem with the system is tossed out in a single sentence: the attack went unnoticed for two days. Wholesale alteration and interception of data passed by completely unmonitored. That's not a problem with the app, that's a problem with the system, and the human processes behind it. And as long as the people who run it aren't secure, even the most watertight app is only going to last as long as it takes someone to pick up a phone.
That should be the headline here.
What I read into that is that the prevention of shell injection attacks is so basic that it's likely that there are other vulnerabilities as well. For example, they're probably saving the name of the stored encrypted file into the database. Since they have a record of not checking the file extension, I'd look for the analogous SQL injection vulnerability when they do the DB insert.
It's a cause for suspicion of further vulnerabilities, but not confidence. One vulnerability is not two vulnerabilities.
From their front-page blog, for instance: http://www.trustthevote.org/d-c-resets-timeline-for-digital-...
"Although we may not all agree with some choices made in how overseas voters are digitally empowered to participate in elections (and the OSDV Foundation for one, remains against widespread application of remote online voting services), I believe that when the efforts of the District are fairly examined, there will be consensus that Rokey Suleman and his team are making a decent effort to do the right thing."
It looks like they pushed hard for a much longer and more aggressive open testing period. See also http://www.trustthevote.org/where-we-stand-%E2%80%93-update-...
Now the original post indicates security concerns spread throughout the system, not just the remote ballot return portion, so it could be there are wider architectural problems. It sounds as if there was significant concerns about this remote return piece, from a key component maker, even before the test started.
Just run a couple hundred lines of code on a high-security processor (or a custom-made hardened chip); if you really must allow internet voting, you could at least take a highly-secure OS and wire up a trusted HTTP server to a well-audited hundred-line CGI program.
But moreover, it's silly to blame the platform. CGI scripts were getting exploited through shell injection vulnerabilities before most of the people here were born.
I'm not sure that there is an exact overlap between the people who believe in freedom to tinker with devices you own, and who believe in security testing in this manner.