The December 2022 issue of IEEE Spectrum is here!

Close bar

Washington D.C. Board of Elections & Ethics Says "Hack our web site, please"

Wanted to test robustness and security of voting site and got what it wished for

2 min read
Washington D.C. Board of Elections & Ethics Says "Hack our web site, please"

The Washington D.C. Board of Elections & Ethics wanted to determine the user friendliness, robustness and security of its prototype elections voting web site "D.C. Overseas Digital Vote-by-Mail" (see this PDF for an overview description). The web site was designed to allow some 950 military and overseas voters cast ballots online, an APstory appearing in the Washington Examiner reports.

So the Board of Elections encouraged outsiders to test the web site out for a week.

Well, last Wednesday, some University of Michigan students "hacked" the web site and embedded an MP3 file of the university's fight song that would play after each ballot was cast.

The D.C. Board of Elections took down the site last Friday, and a scaled-back version was relaunched yesterday - without the fight song. The Board of Elections is still hoping to be able to use the site for the November elections, assuming that it stands up to continued scrutiny.

According to the AP story:

"The relaunched site will allow voters to download ballots, but not cast them online as originally planned. Instead, they'll have to mail, fax or e-mail them in. The system is still an improvement over past years when overseas voters were sent their ballots by mail."

The Board of Election plans to restore the ballot-casting feature in 2011.

More interestingly to me is how the Board of Elections went about testing the system. They set up a credential system for testers (and hackers) and then gave them the source code and the layout of the servers (see PDF) on which it executed. Some 100 people requested credentials to participate, including a professor at the University of Michigan who asked his students to try to hack the site.

The Board of Elections has received about 50 comments so far on how to improve the site or errors experienced when testing it out.

The D.C. Board of Elections deserves praise for what it did, even though their site was hacked fairly quickly. The effort hopefully will result in a much better and more secure web site in the future.

It would be nice to see other government and private organizations - the IEEE included - do the same thing with their sites.

Update 07 October 2010: 0930 EST

There were two useful stories yesterday (here and here) in ComputerWorld that provides a bit more information on the University of Michigan students' hack attack.

According to ComputerWorld, it was Professor Alex Halderman's class that did the hacking. He an assistant professor of computer science at the University of Michigan.

Professor Halderman is reported in ComputerWorld to have said that the security hole discovered (a shell injection flaw)  was serious, and that they could "access the database username and password and the public key used to encrypt ballots. In addition, [they] found [that] they could install a backdoor on the server for viewing and recording votes and the names of those who cast them."

In addition, the article says that the Digital Vote by Mail application "is based on software from the Open Source Digital Voting Foundation, a group developing voting systems based on open-source technology. It's written using the Ruby on Rails framework and runs on an Apache Web server and MYSQL database... "

You can find out more what Professor Halderman and his students found at this blog post.

The Conversation (0)

Why Functional Programming Should Be the Future of Software Development

It’s hard to learn, but your code will produce fewer nasty surprises

11 min read
Vertical
A plate of spaghetti made from code
Shira Inbar
DarkBlue1

You’d expectthe longest and most costly phase in the lifecycle of a software product to be the initial development of the system, when all those great features are first imagined and then created. In fact, the hardest part comes later, during the maintenance phase. That’s when programmers pay the price for the shortcuts they took during development.

So why did they take shortcuts? Maybe they didn’t realize that they were cutting any corners. Only when their code was deployed and exercised by a lot of users did its hidden flaws come to light. And maybe the developers were rushed. Time-to-market pressures would almost guarantee that their software will contain more bugs than it would otherwise.

Keep Reading ↓Show less
{"imageShortcodeIds":["31996907"]}