Slashdot Mirror
Voting System Test Hack Elects Futurama's Bender To School Board
mr crypto writes with this quote from El Reg:
"In 2010 the Washington DC election board announced it had set up an e-voting system for absentee ballots and was planning to use it in an election. However, to test the system, it invited the security community and members of the public to try and hack it three weeks before the election. 'It was too good an opportunity to pass up,' explained Professor Alex Halderman from the University of Michigan. 'How often do you get the chance to hack a government network without the possibility of going to jail?' With the help of two graduate students, Halderman started to examine the software. Despite it being a relatively clean Ruby on Rails build, they spotted a shell injection vulnerability within a few hours. They figured out a way of writing output to the images directory (PDF) on the compromised server, and of encrypting traffic so that the front-end intrusion detection system couldn't spot them. The team also managed to guess the login details for the terminal server used by the voting system. ... The team altered all the ballots on the system to vote for none of the nominated candidates. They then wrote in names of fictional IT systems as candidates, including Skynet and (Halderman's personal favorite) Bender for head of the DC school board."
the election board had the common sense to ask for this publicly and not cross their fingers and hope no one did this when they used it for real. More gov't entities should open up to testing like this.
Every single technology profession I have EVER communicated with, does not think electronic voting machines are a good idea. If EVERYONE is in agreement this is a BAD idea, why the FUCK are we still making these things?
Indeed.
Ruby does a lot of things, but encouraging security isn’t one of them. Building a properly secured application means thinking about security right from the beginning and working it in at the core levels. Upper level code shouldn't even be _able_ to do something insecure without some kind of token from the minimalist security layers at the base. A language designed to "handle that shit for you" leads to a lot of "oh, didn't think about that" type issues.
See also: diaspora
What I want to see is a real compromise of one of these systems that can be held up as a true scare story:
1. The compromise is undetected. At the time the results are reported, the election officials are unaware that the system has been compromised and none of the systems in place for detecting a compromise has indicated any trouble. According to all evidence in the audit trail the results are undeniably correct and true.
2. There was no indication of tampering at the time of voting. As votes were being cast there was no indication of tampering with the ballots or any other visible indication that the results weren't being correctly recorded and reported.
3. The results reported are undeniably wrong. Eg., the test voting was done in a controlled manner where everyone knew what the correct results should be and that everyone saw that everyone else had voted the way they were supposed to, so if the system functioned correctly it's known exactly how many votes should be cast for which candidate.
4. The reported results are undeniably wrong. Eg., according to the reported results 100% of the votes cast were for a candidate who should've received zero votes.
Nice troll. Actually, it's kind of a lame troll. I suppose, as is normal on /., you didn't read the report from Prof Halderman.
The initial problem was a string interpolation vulnerability in a modified Ruby library that executes a shell command to encrypt PDF ballots. That's a pretty basic mistake that has nothing really to do with Ruby or Rails. If you interpolate into a string (or concatenate data into a string) without sanitizing the data, and then execute it, you're asking for trouble, no matter whether it's Rails or Java or C. This is also pretty basic security stuff, and there are tons of guidelines and tutorials in the Rails community for avoiding this kind of mistake. There are also plenty of code vulnerability scanners that would pick this up. It's amazing that the DC team didn't use one of these to check their code.
But they had plenty of other problems such as easy-to-guess passwords and a lousy IDS configuration.
So the real problem was with the people who developed and implemented the system, not with the tools. I've seen plenty of similar mistakes in systems developed using all sorts of technologies. The developers clearly didn't have a very solid background in security. That's OK actually, as long as you have someone on the project who does and who can check their designs and implementation. Sounds like they didn't have anyone well versed in security, which seems a bit odd for an e-voting project. I'm certainly no expert on security, but I am RoR coder, and even I know not to make these mistakes.
But I suppose it's fun to bash the Rails programmers because they are in really high demand and able to command very high billing rates :-) I'll take the bashing along with the money and the ease of programming!
I really hate Ruby, but its hard to ignore that there's a ton of Ruby shops hiring in the big north american metro areas and that they have more contracts than they can deal with right now. Ruby is pretty hot these days.
It's not news that electronic systems can be insecure. Those selecting such systems are certainly lobbied to believe that, whatever system they choose, "this time it will be different... this one IS secure."
The truth is all voting systems -- manually or electronically administered -- are insecure. The feature that traditionally manual voting systems have is that the scale of voting fraud exacted is correlated with the scale of corrupt election officials overseeing the process. To increase fraud you either need a) more conspirators or b) higher-level conspirators in the body that oversees the process. That is a feature that is worth keeping in any new version of voting system.
This article is just another example of a voting system that has given up the feature. Not all electronic voting systems forsake this feature, but those that keep it are at most electronic-assisted voting systems that retain distributed verification at multiple stages of the counting process. That's because voting is most secure when it's a distributed activity, not a centralized one. With thousands of tiny precincts collecting pockets of votes, any one could tamper with results -- but many would have to tamper to have a big impact. Election commissioners, keep this feature!
This was a system created by Rubyists. They don't understand security because that's a "low-level detail" they can't be arsed to learn.
Rubyists pay attention to low-level details. This is why we write C extensions rather than executing shell commands from web applications, which is asinine.
"Rails developers" are rarely Rubyists, properly speaking. This is one of the issues plaguing the Rails community. It could be worse, though. Rails developers can become Rubyists. In the PHP community, given that the preferred development methodology seems to be having two cats copulate on a keyboard, I don't hold much hope.
To understand recursion, you must first understand recursion.
Why even use passwords. This is the kind of system that should require a two factor authentication. You shouldn't be able to gain access to an election system unless you actually have the key to the ballot box.
"I am a poll worker in Virginia, and we follow a very similar protocol for our DRE voting machines. "
While it sounds like you're trying to do a good job, there are many fundamental problems with DRE machines.
- The software is proprietary, and not open to inspection, only to "black box" testing, which cannot only detect some kinds of errors, and cannot be counted on to detect all errors or intentional fraud.
- There is no way to prove that the vote recorded by the DRE is the same as the vote cast. The lack of voter verification of the actual recorded vote is the fundamental problem with DREs, rendering them unsuitable for use in elections. Note that printing a record of the vote within the machine does not help, because the receipt inside the machine is not verified by the voter, so there's no way to validate that it reflects actual votes cast, so it cannot be used as the basis of an audit or recount.
- There is no way to prove that the vote recorded by the DRE cooresponds to the votes reported.
- There is no way to audit reported vote counts against actual votes cast, so no way to discover fraud or error in the voting system.
- There is no way to recount actual votes cast by voters. You can recount whatever the software happened to record, but that can easily be different from the vote cost.
Or, as NIST put it "Simply put, the DRE architecture’s inability to provide for independent audits of its electronic records makes it a poor choice for an environment in which detecting errors and fraud is important."
There are advantages the electronic voting systems, such as providing immediate voter feedback to prevent overvoting and warning of undervoting, and assisting seeing impaired voters.
The right way to go, I believe, is to use electronic voting systems to assist voters in producing a paper ballot (AKA the Voter Verified Paper Ballot), which the voter can then inspect and cast. That gives the advantages of a DRE, but with the added benefit that the election results can be (relatively) trusted. That is, for example, the type of system used in Nevada after the Gaming Commission rejected all of the DRE systems. This is particularly relevant, because they're the only state with significant experience in securing DRE-like devices, because they certify gambling machines, which are under similar attacks to DREs.
Check out http://www.openvotingconsortium.org/ for an open source system that does the right thing.
Enable 3D printed prosthetics!