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

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.

Of course, that's all fun and games, but this revealed a bunch of serious issues. Beyond the fact that the hack basically gave them total control of the system (yikes) and the fact that any intrusion detection system didn't work even though these guys did almost nothing to hide their trail, they were also able to install:

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

How?

I hate to be this guy, on a forum that's topically legal in nature, but this is so old school, I cant stand it.

I'm astounded that any security minded architect would use the command line interface for anything at all. Even the disk written to has a viable interface wrapper in any language take your pick. I'm not saying there aren't vulnerabilities mind you. What I *am* saying is that upload of anything must be reproduced by the applications software in a DMZ before entering the data handler. That's 101 since forever. I'm really surprised at this level, given the sensitivity of the data, and the obvious vector for attack, that these methods would be employed at all? Call HP or someone that does a security audit of source code design before handing over tax payer money. This would have been identified in the initial sweep.

On the other hand, I recon we just aint gonna trust them fangled computers to make Democracy. We just aint got the technology. Oh well, suppose electing them politicians/lobbyists is the best we gonna get.

Re: How?

There are ways to use the command line interface securely. The exec() family of system calls, which is what actually runs a program, has a separate parameter for each command line argument (unlike the clusterf* that is Windows' CreateProcess), and they are passed unmodified directly to the target program. There is no way this kind of vulnerability can happen when you call programs in this manner.

What they did wrong was probably to use system() and variants. These call the shell to run the command line you passed (as a single string with all the parameters mashed together). Unless you are really careful with the escaping (and sometimes not even then), the shell is going to interpret the command line on its way. With that I agree with you; there is no way any security minded architect would call the shell to run a program instead of going the more secure exec() route.

Re: Re: How?

I'm sure it can be done, if you used a VM or some other insulated package. The point here is, for 3xA security, the System call is should never be a first tier solution. Especially to such a common task. Using libs (o/dll) to invoke or expose the desired functionality without commitment is always preferred over nixing security domains all together.

Re: How?

Sometimes you can't reasonably avoid executing an external command. The real problem is delegating the job of passing arguments for that external program to a system's shell. It's surprising how hard most mainstream programming languages make it to call an external program without using a shell. This is the same problem C has had for decades now with buffer overflows, everyone knows how to prevent them, but it's harder to do it right then to do it wrong, and it only takes doing it wrong once for an exploit to work.

Unsecure, but in the wrong way

I guess this supports the idea that these kinds of vulnerabilities are not part of some government conspiracy to allow tampering with votes by a select few. If you want to control who gets elected, you wouldn't do so using an exploit that the unwashed masses could access. You'd want a back door into the system that would only allow the select few to control the results.

My point isn't that there aren't government officials that wouldn't want to or have even tried to corrupt e-voting; just that these kinds of vulnerabilies don't support this premise.

Incidentally, I do support open source for e-voting machines/systems, but even this wouldn't prevent the introduction of a back door. They could publish all the source code and have it be reviewed by millions and, at the last minute before compiling, add a back door.

Re: Unsecure, but in the wrong way

Re: Re: Unsecure, but in the wrong way

You forgot to mention Thompson's attack.

Thanks for giving me the benefit of the doubt, but I didn't so much forget it as never knew about that in the first place. But...very interesting reading. It just goes to show that even what you think is the most thorough review can sometimes not find the vulnerability in the system.

Re: Unsecure, but in the wrong way

I guess this supports the idea that these kinds of vulnerabilities are not part of some government conspiracy to allow tampering with votes by a select few.

or it supports the idea of plausible deniability for voter tampering: a system that is known to be insecure creates a group of people to blame other than the group responsible. it's a sort of reverse occam's razor.

Does anyone still think Bush won the 2000 "election"?

Or that fellow Skull-and-Bones member Gore was actually an alternative? Electronic machines of some sort were in crucial areas, and their counts never add up, aren't really auditable. But the main lock on the election is that whichever "candidate" gets into office, the Establishment wins.

@Hulser: how does this rule out conspiracy by politicians? Just because it'd be available to "the unwashed masses" if known? And on what evidence do you claim that backdoors don't exist TOO?

The *only* balloting that's at all secure is *paper*, and which can be re-counted accurately.

I guess this supports the idea that these kinds of vulnerabilities are not part of some government conspiracy to allow tampering with votes by a select few. If you want to control who gets elected, you wouldn't do so using an exploit that the unwashed masses could access. You'd want a back door into the system that would only allow the select few to control the results.

Not really - if it's ever discovered that some type of fraud did in fact take place, having tight security that only a few can get past takes an IMMENSE amount of options away from one's "plausible deniability".

If you are the only one with a particular level of access and the system is compromised the 'possible' people who could have done it is narrowed substantially. If there are 'gaping holes' then the range of potential offenders increases dramatically, allowing for "plausible deniability" by those who really compromised the system.

Then in the end if fraud is uncovered the 'select few' are immediate suspects with not much in the way of defense to the contrary. But if there are large gaping holes, then it's easy to say some 'random hacker' did it, with evidence that's admissible in court to backup that "poor security" defense. Allowing the real guilty parties to not only get out of legal issues, but allows the 'system' as a whole an 'out' in the court of public opinion.

In the end, REAL tight security on a voting machine will result in a quite possible arrest of the real guilty party if only a few could potentially instruct the machine to change the votes. If there are wide gaping holes; then any uncovered fraud can be finger-pointed away at some programmer or company, rather than the admin or two that have access to a highly secure system.

Re:

Not really - if it's ever discovered that some type of fraud did in fact take place, having tight security that only a few can get past takes an IMMENSE amount of options away from one's "plausible deniability".

I disagree. Imagine some secret government cabal. Their trusted tech guys presents to them a plan whereby they can control the election results using a "shell-injection vulnerability". The catch? That a bunch of college kids could also control the election results if they figure out the hack. Oh, and by the way, it's been proven that hacks like these can be discovered in a matter of days with relatively little effort. I've never made a pitch to a secret government cabal -- that you know of -- but I'd be fearful of my job (if not my life) if I presented a plan like this. Plausible deniability might be a factor, but it would be so overshadowed by the possibility that the system would be rehacked that it wouldn't be worth the effort.

These are the same people that think an IP address identifies a specific person. Did you think that because this is integrated in one of the cornerstones of our country that these people would suddenly become technically savvy? Did you really think that the whole Cyberstorm 3 was anything more than a play-dance to get more money to bomb the crap out of someone else (not that I'm against bombs...explosives can be fun) or siphon pork to whoever paid them off.

These people did exactly what all the C level executives that you work with everyday did. "OHHHHHHH, PRETTY! OHHHHHHH, SHINY! Must Have." They were totally thinking about the BCS when the consultant was discussing the security limitations during the implementation. When the time came to pony up the dollars to secure the system, well, now...

Lets give some credit to DC

Washington DC did the right thing by opening the system for security review.

Computer security tends to be brittle. When it is broken, it is generally completely broken.

Unfortunately most of the discussion has been about how DC built a bad system, instead of discussing how DC built a process for testing a system. Congratulations DC, you did a good thing. It is hard work to build a secure system because they are brittle, but the most important step is testing.

While there are lots of ways of improving this rather deficient test plan, I'm sure that DC will do a better job of testing next time. After this experience, they know the value it provides.

Let's *not* give credit to DC. They may have expected to fool us.

Electronic voting machines of *any* variety are suspect. They are inherently black boxes with the only audit trail possible coming from within the suspected devices themselves!

To encourage a "next time" is stupid. Even if *all* testers can't find a flaw, that provides *zero* assurance that the system isn't controlled in secret. A little digging into what's already known about fraud using these mechanisms should dissuade anyone honest from advocating them. -- Why do you think politicians want them in the first place?

Election Integrity activists have been saying it

Trust long-suffering election integrity patriots who have devoted YEARS of their lives pointing out the extensive election fraud perpetrated on the nation.
Bev Harris and Brad Friedman have the goods on electronic voting systems and opscan counters of ballots- these systems allow easy mass manipulation of election day results. The criminals behind these machines include a former Florida Congressman - Tom Feeney. Read all about it and then back election integrity witness and whistleblower Clint Curtis who is now running for Congress in California.
It is people like Bev, Brad and Clint who should be supported and elevated to positions of power so we can once and for all remove fraud-enabling electronics from all of our elections.