The Details On How To Elect Futurama's Bender To Whatever Election Is Using Online Voting

from the bite-my-shiny-metal-ass dept

Back in October of 2010, we wrote about how some “hackers” had broken into a test of the Washington DC e-voting system, and had managed to have the system play the University of Michigan “fight song” every time people voted — University of Michigan being where the researchers (led by e-voting security expert J. Alex Halderman) were from. A day later, we discussed some more details of the hack, noting how just a tiny vulnerability could take down the integrity of the entire system.

It’s been a bit of time since then, but Halderman has released the academic paper they wrote about the experience, which is now getting some new attention, including the fact that, beyond playing the UMich fight song, they also installed their own slate of “fictional” candidates, including Bender from Futurama, who is presumably running on a Kill All Humans platform.

The full paper has some other interesting tidbits, as well, including the fact that they didn’t just hack into the e-voting machines… but also accessed the security cameras watching the e-voting servers, which were left open to public access. I’m not kidding.

While that might not seem like such a big deal, as the researchers noted, it was actually really useful:

These webcams may have been intended to increase security by allowing remote surveillance of the server room, but in practice, since they were unsecured, they had the potential to leak information that would be extremely useful to attackers. Malicious intruders viewing the cameras could learn which server architectures were deployed, identify individuals with access to the facility in order to mount social engineering attacks, and learn the pattern of security patrols in the server room. We used them to gauge whether the network administrators had discovered our attacks—when they did, their body language became noticeably more agitated.

Either way, the entire thing suggests just how insecure e-voting can be, and the paper suggests these are fundamental, systematic problems with any e-voting approach these days, rather than just a poor implementation.

Filed Under: , , , , , ,

Rate this comment as insightful
Rate this comment as funny
You have rated this comment as insightful
You have rated this comment as funny
Flag this comment as abusive/trolling/spam
You have flagged this comment
The first word has already been claimed
The last word has already been claimed
Insightful Lightbulb icon Funny Laughing icon Abusive/trolling/spam Flag icon Insightful badge Lightbulb icon Funny badge Laughing icon Comments icon

Comments on “The Details On How To Elect Futurama's Bender To Whatever Election Is Using Online Voting”

Subscribe: RSS Leave a comment
mariush (profile) says:

From the paper

Wow… just wow…

However, we found that the Paperclip Rails plugin used to handle file uploads stored each ballot file in the /tmp directory before it was encrypted. The web application did not remove these unencrypted files, allowing us to recover

After about 3.5 hours using the cracker?s default settings, we recovered the secondary administrator password cisco123 from a salted MD5 hash.
When we inspected the terminal server?s logs, we noticed that several other attackers were attempting to guess the SSH login passwords. […] We realized that one of
the default logins to the terminal server (user: admin, password: admin) would likely be guessed by the attacker in a short period of time, and therefore decided
to protect the device from further compromise [..]

Typical “win project, contract it to the cheapest programmers” stuff..

Rich Kulawiec (profile) says:

I've been saying this for years

The problems with e-voting are not just at the implementation layer — although those are clearly numerous and catastrophic, as we’ve seen over and over and over and over again. There are also problems at the architectural and procedural layers, and those are even worse: at the moment, they remain unsolved.

Voting machine vendors have of course emulated Mohammed Saeed al-Sahaf, Iraqi Minister of Information in their denials of all this. They’ll continue to do so, therefore the gullible, techno-illiterate buffoons at the local/state/federal level will continue to waste hundreds of millions of dollars on equipment that not only doesn’t work, but isn’t going to work.

The best available solution to this problem remains one of the simplest: pencil and paper. It’s not glamorous, it’s not high tech, it’s tedious…but it’s also (if properly administered) very well understood and thus extremely hard to game. Given the important of election results, I think it’s completely acceptable to undertake the onerous task of counting ballots by hand, and equally acceptable to tell the public that it may take a week.

Anonymous Coward says:

All of this security hardening on e-voting systems is great, but in terms of systematic problems, they are no different in paper voting (non e-voting). In terms of security, storage, transport, counting, etc. (wherever humans are concerned) will have similar systematic problems. It would be great to see a security team attempt to breach the existing non e-voting system. I think that would provide some very interesting results.

Greg says:


I disagree. The problems are similar, but the scale is different. With any computer-based program, it’s vastly easier to make bulk changes since you can use the power of the computers themselves to distribute the attack. In the real world, you would need a massive coordinated effort to achieve the same result. Ballot stuffing and similar electoral fraud techniques require many, many people in the right places to accomplish. Hacking can get much greater results with only one or a few people.

Rich Kulawiec (profile) says:


but in terms of systematic problems, they are no different in paper voting (non e-voting).

Ah, but they are different. It’s certainly true that there exists a class of problems which applies equally to both (for example: vote purchasing), but there are several large classes of problems unique to e-voting: architecture, hardware, software, network, for starters. Nobody has yet demonstrated the ability to build a system that’s even plausible secure and reliable, let alone one that has been shown to be so when confronted with clueful attackers.

Eight years ago, Bruce Schneier posted this chilling analysis: Stealing an Election. Here’s the money quote: So when designing the security behind the software, one must assume an attacker with a $100M budget.”

That was in 2004. What’s the number today? And what tiny fraction of that did the researchers involved here need to not just compromise, but utterly destroy the security of the DC setup?

A hundred million dollars may sound like a lot…but if you look at what’s ALREADY been spent in 2012 on just the US Presidential campaign, let alone all the Congressional and other races, you’ll see that it’s a bargain. There are people out there ready, able and willing to cut that check if it will buy them the results they want.

Anonymous Anonymous Coward says:

Open Source the Design and Test Test Test

I would love to see an open source effort in this area. I agree with the above statement that even the pencil and paper system has issues. The goal of this suggested effort would be to make it more secure than pencil and paper, since it is probable that totally secure is an unreasonable goal.

I am suggesting that such a system be designed from the ground up, including all hardware, and all software being not only open, but available for inspection by anyone and patent free. Triple redundancy, special hardware firewalls, local DVD backups and all the ideas I have not thought of.

Then, put the system on the net and let everyone have at it for say a couple of years. White hat, black hat, gray hat, red hat, and purple hats with feathers. At some point the number of vulnerabilities will approach 0. Then let the statisticians do some calculating to determine the risk of this electronic system vs the paper and pencil (or any other system).

I may be accused of being overly optimistic, but I do think we can do better.

:Lobo Santo (profile) says:

Open Source the Design and Test Test Test


In short–the cryptographer’s dilemma: It is assured that YOU can design an encryption which you cannot break; but that in no way means it’s any good.

The only way to know if it’s good is to open-source it–feedback from one’s peers lays bare all the flaws in your design.

Without that feedback and perspective, you never quite know if you’re submitting a shiny polished turd or a shiny flawless diamond.

TtfnJohn (profile) says:

Open Source the Design and Test Test Test

And before some AC jumps all over this by saying that if the code is open sourced then attackers only need to read the code to crack it I just want to add this.

Open source is, by and large, more secure by an order or two of magnitude to closed source as has been demonstrated over and over again.

E-voting can certainly do better but I’m firmly of the opinion that pencil and paper is far better.

Rich Kulawiec (profile) says:

Open Source the Design and Test Test Test

Open-source software is clearly a necessary prerequisite, but it’s not a sufficient one. To point out just one (of a great many issues): read the comment I posted which cites Bruce Schneier’s $100M number for the attackers’ budget. With that kind of money to throw around, attacks based on hardware are possible.

And it won’t matter what the code says it’s doing, if the underlying hardware is ignoring it.

Beta (profile) says:

playing fair-- until they lose

I was all set to praise the BOEE for allowing a public black hat trial of their system — it’s the right thing to do in so many ways — until I got to this part:

‘The attack was apparently brought to officials? attention by an email on a mailing list they monitored that curiously asked, ?does anyone know what tune they play for successful voters?? Shortly after another mailing list participant recognized the music as ?The Victors,? officials abruptly suspended the public examination period, halting the tests five days sooner than scheduled, citing ?usability issues.?’

I would have had a hell of a lot more respect for them if they had cited “massive breach”. They were happy to hold a trial they were sure of winning, and as soon as they were beaten they went right into whitewash mode.

Anonymous Anonymous Coward says:

Open Source the Design and Test Test Test

I believe I included the Hardware in open sourcing. Why yes I did.

The only part that would not be able to change is that part that goes over the Internet, though I think there are opportunities there with encryption and possibly multiple routings. I think that that part might be the greatest vulnerability, hence the suggestion for local DVD backup, which would be best done in real time. Then one could compare the write once read many DVD’s to the reported results to see if there are issues.

Rich Kulawiec (profile) says:

Open Source the Design and Test Test Test

1. Read this — it’s Ken Thompson’s Turing Award acceptance speech (from nearly 20 years ago):

2. Think about its applicability here.

3. Consider that you do not have a wafer fab plant in your basement, so you can’t create the hardware, even if you know how and even if you really, really want to.

4. Consider how hard it is to find even an accidental bug in hardware, even when you’re working with open-source software. How much harder would a deliberate one be to uncover?

5. How do you know that this hasn’t already happened?

Anonymous Anonymous Coward says:

Open Source the Design and Test Test Test

Agreed. But I don’t think they designed the hardware for a single purpose which I think would make a big difference. Also, what would happen if they took the lessons learned, and re-wrote the software portion and tested again? And then repeated that cycle? If they went through, say 24 iterations of lessons learned and re-writing over a couple of years, could they not reduce the issues significantly?

silverscarcat says:


Don’t worry, Robin! The Bat Computer can analyze the system flaws in under ten minutes.

Then with my Bat System analyzer, I’ll be able to fix the flaws in twenty minutes.

Then with my Bat Hacker device, I’ll be able to break the hacking codes all around the world, Robin.

It will only take me an extra thirty minutes.

Anonymous Anonymous Coward says:

Open Source the Design and Test Test Test

I think I get your point about the Turing award speech, though I am not a programmer, and it is a bit over my head ( I have had some experience in Project Management with a large bank that had a great interest in security).

My thought process was to create a system that has a single purpose (record votes accurately) from the ground up (hardware and software and then seal the system from outside changes), which after reading this would include the compiler, and not in a vacuum.

They would need to keep the system to the simplest possible architecture to improve the ability to find issues. This would increase the possibility of having fewer bugs, intentional or not. The long testing process would give opportunity to find any unintended issues.

Once again, I do not believe that a totally error free system would come out at the end, but one statistically able to beat the paper and pencil system we have used historically, and most certainly better than the closed electronic voting systems hyped by the likes of Diebold.

BentFranklin (profile) says:

Open Source the Design and Test Test Test

A few other things to remember:

1. Due to the loss of information that occurs when you separate the voters’ names from their ballots, there can never be a perfectly auditable or verifiable election.

2. You also have to protect the election from the people who are running it. There is very little defense against a corrupt admin. Measures that would purport to do so likely make the system unusable. The same is true for paper ballots.

Rich Kulawiec (profile) says:

Open Source the Design and Test Test Test

You’re certainly right that a design process focused on simplicity is the way to go; and certainly one that includes huge amounts of peer review would be highly desirable. Such an approach would absolutely beat the systems from Diebold, but frankly that’s very, very low bar to clear: those systems are the kind of garbage that would earn a college sophomore a failing grade.

But…trying to best paper-and-pencil systems is much harder. These systems are difficult to game in part because of their inherent simplicity, but also because they’ve been around for a very long time, and thus have been subjected to all manner of attacks. Those attacks have been catalogued, studied, analyzed, and as a result there now exist robust procedures to defend against them. Could we develop those as part of the process of developing substantially stronger e-voting systems? Yes. But we haven’t yet, and if history is any guide, that development will take much longer than the development involved in the technology itself.

(As an analogy: we have all kinds of technology designed to facilitate pretty secure online banking. Yet people get phished all day, every day. Why? Because the procedures associated with the technology absolutely suck. And banks themselves are a large part of that problem.)

Anonymous Anonymous Coward says:

Open Source the Design and Test Test Test

You are correct, no system will be perfect. Banks have one big issue that keeps getting in their way. Profit. They make descisions based on what will cost them less, developing a more secure system, or eat the losses. Take away that motive and lots of issues fall by the wayside.

That idea, however, does not remove the issue of the (profit or control) oriented person or group. If cost is less of an issue, along with the peer reviewing, the typical three legged stool of developement becomes more balanced. (cost, features, deadline). The feature set would be fixed from the begining. The time element would be iterate until the statistics beat paper and pencil. The cost would be whatever it takes.

It takes the correct motivation, along with the other factors we have both mentioned. Spending a significant amount of time on defining the feature set, architecture, and design will go a long way towards making
it better.

Prisoner 201 says:

I've been saying this for years

I like pen and paper voting, precisely because it is inefficient – the number of people that must be corrupted/bribed/threatened to have a significant impact on the result should be large enough that keeping it under wraps becomes very difficult.

Imagine a lone sysadmin with the power to alter the outcome of the elections?

One admin to rule them all…

herve leger (user link) says:

herve leger sale

Herve Leger nowadays has grown for being recognized internationally. Herve Leger Dress New is all about new style of 2012. Herve Leger v neck dresses has owned every woman’s heart. Herve Leger Sleeveless Dresses will be the hottest item in this summer and Herve Leger Strapless dress can make you be the lightspot among the crowd street. Karen Millen is also specializes in women’s dresses, it make women look elegant and sophisticated.

Add Your Comment

Your email address will not be published. Required fields are marked *

Have a Techdirt Account? Sign in now. Want one? Register here

Comment Options:

Make this the or (get credits or sign in to see balance) what's this?

What's this?

Techdirt community members with Techdirt Credits can spotlight a comment as either the "First Word" or "Last Word" on a particular comment thread. Credits can be purchased at the Techdirt Insider Shop »

Follow Techdirt

Techdirt Daily Newsletter

Techdirt Deals
Techdirt Insider Discord
The latest chatter on the Techdirt Insider Discord channel...