
Hacking the D.C. Internet Voting Pilot - ssclafani
http://www.freedom-to-tinker.com/blog/jhalderm/hacking-dc-internet-voting-pilot
======
d_r
This may be stating the obvious, but I can log in to my online bank and
presumably transfer money without any dollars ending up unaccounted. I
(hopefully) can't go in and tamper with my balance. Are banks that much better
at software, or have their flaws just not been discovered yet?

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.

~~~
JeffJenkins
It's pretty clear that the voting machine manufacturers are doing an awful
job, and not even the basic security they need, but there are some particular
difficulties to voting.

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...](http://www.schneier.com/blog/archives/2004/10/getting_out_the.html)

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.

~~~
eli
Notably, this DC pilot program _was_ using open source code. It's right here
<http://github.com/trustthevote/DCdigitalVBM>

------
loewenskind
This kind of thing really irritates me. _Why_ are we piloting anything? Brazil
has this solved! They have a system with much harder restrictions than what
the US currently has [1] and their system has been working fine for years.
Don't write a new one, just buy theirs!

[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.

~~~
CWuestefeld
Why are people downvoting this? It seems a legitimate question to me.

loewenskind, can you provide links to more information?

~~~
loewenskind
I learned about it from a Brazilian who used to work with these machines. I'll
have to ask him for something online (thought it may mostly be in Portuguese).

------
Cushman
This sort of security article rubs me the wrong way. It's obviously written
for the layman; someone who doesn't know what a "shell injection attack" is or
what it enables. Thus it goes into great detail about the things that are
possible if you can run arbitrary code as root (or the app user, just as bad).

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.

~~~
CWuestefeld
_You say that you're "confident" you could have found another attack-- do you
mean..._

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.

~~~
Cushman
Or conversely, the shell injection vulnerability is fairly obscure —
forgetting to validate the extension, not something you'd usually think of as
user-provided input. This indicates that there was a modicum of concern for
validation, they just weren't approaching it rigorously.

It's a cause for _suspicion_ of further vulnerabilities, but not _confidence_.
One vulnerability is not two vulnerabilities.

------
gbhn
Digging a bit more into TrustTheVote, it looks like the project had serious
reservations about this application from the start.

From their front-page blog, for instance: [http://www.trustthevote.org/d-c-
resets-timeline-for-digital-...](http://www.trustthevote.org/d-c-resets-
timeline-for-digital-vote-by-mail-service)

"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-...](http://www.trustthevote.org/where-we-
stand-%E2%80%93-update-on-the-d-c-overseas-distance-balloting-project)

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.

------
JoachimSchipper
To be honest, I wasn't surprised at all as soon as I saw "It's written using
(...) Ruby on Rails (...) and (...) MySQL (...)" - seriously, for a project
where pretty much the _only_ requirement is security, why go with such a
complicated stack?

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.

~~~
eli
Security surely isn't the _only_ requirement. There was a relatively modest
budget and a firm deadline.

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.

------
slapshot
Possibly a good project, but seems odd to come from FTT. This seems like more
than just freedom to tinker with devices you own and extend into outright
security vulnerability scanning.

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.

~~~
joeyo
Ed Felten and the other freedom-to-tinker bloggers have a pretty long history
of interest in electronic voting.

<http://www.freedom-to-tinker.com/tags/voting>

