Details Of How The DC Online Voting System Was Hacked: Small Vulnerability, Huge Consequences
from the validate,-validate,-validate dept
We already wrote about the news that some folks at the University of Michigan had successfully hacked an online voting trial in DC, and suggested that Alex Halderman was the guy behind it (though, he was not identified in the press). Halderman has now written a blog post noting that, indeed, it was him and a few others, and providing a pretty thorough explanation of what happened. The DC project had called on anyone to try to hack it during an open hack period, though they only gave three days notice. Still, it didn't take long for Halderman, two PhD. students and a member of UMich's technical staff to find a vulnerability: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:Also, while the press pointed out the fact that after people voted the University of Michigan fight song played, that was hardly the only thing that these researchers did. The reason it got attention was that after they successfully made a bunch of changes to the system, they didn't tell anyone just to see how good the voting system's intrusion detection system was -- and it still took a while for anyone to notice. And it wasn't even the voting system folks who figured it out. Apparently, it was other testers who came across the fight song (hence that being what got reported in the press). They also changed all the votes to write-in candidates they liked and set the system to automatically change all future votes to the same candidates. You can see the ballot that they used to replace all of the votes below. You might like some of their write-in choices.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.
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.Think about that for a second. This wasn't just a little hack. This was a big, big deal, for a voting system that someone had hoped to actually use in real elections next month. As Halderman notes, this does not bode well for internet voting:
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.And just think: this was done in just a few days with a voting commission that was open to outsiders trying to hack the system. In the meantime, most of us will use electronic voting equipment next month that has not been subject to any sort of tests like that, and probably includes similarly damaging vulnerabilities (though, thankfully, not via the internet).
Filed Under: alex halderman, dc, online voting, security
