Security flaw in New South Wales puts thousands of online votes at risk

Update April 26: The technical paper is now available

Update Mar. 23 1:30 PM AEDT: Our response to the NSWEC’s response

New South Wales, Australia, is holding state elections this month, and they’re offering a new Internet voting system developed by e-voting vendor Scytl and the NSW Electoral Commission. The iVote system, which its creators describe as private, secure and verifiable, is predicted to see record turnout for online voting. Voting has been happening for six days, and already iVote has received more than 66,000 votes. Up to a quarter million voters (about 5% of the total) are expected to use the system by the time voting closes next Saturday.

Since we’ve both done extensive research on the design and analysis of Internet voting systems, we decided to perform an independent security review of iVote. We’ll prepare a more extensive technical report after the election, but we’re writing today to share news about critical vulnerabilities we found that have put tens of thousands of votes at risk. We discovered a major security hole allowing a man-in-the middle attacker to read and manipulate votes. We also believe there are ways to circumvent the verification mechanism.

iVote allows voters to register and cast their votes using websites managed by the Electoral Commission. Upon registration, voters are given an 8-digit iVote ID number and asked to choose a 6-digit PIN. These allow them to log in to an online voting application implemented with JavaScript and HTML. After casting their vote, they receive a 12-digit receipt number. Optionally, the voter can call a telephone verification service and enter their receipt number to hear an automated system read their vote back to them.

The Electoral Commission has not published any of the source code for the election servers, but they have made available a practise voting site that uses substantially the same client-side code as the real voting site. We investigated the system by reviewing hundreds of pages of design documents and studying the client-side code of the practise site and the login screen of the real voting site.

Critical vulnerabilities

The iVote voting website, cvs.ivote.nsw.gov.au, is served over HTTPS. While this server appears to use a safe SSL configuration, the site included additional JavaScript from an external server, ivote.piwikpro.com. (Piwik is an analytics tool used to track site visitors.) As can be seen using the SSLLabs SSL Server Test, the ivote.piwikpro.com server has very poor security. It is vulnerable to a range of SSL attacks, including the recently discovered FREAK attack.

iVote includes JavaScript code from ivote.piwikpro.com

ivote.piwikpro.com scores an F for SSL security

We confirmed that a man-in-the-middle attacker could exploit the FREAK attack to manipulate the voter’s connection to ivote.piwikpro.com and inject malicious JavaScript into the iVote site. This code could arbitrarily change how the site operates without triggering any browser security warnings. FREAK affects major desktop and mobile browsers, including Internet Explorer, Chrome, and Safari, and while the browser makers have released fixes over the last two weeks, many users haven’t updated yet.

We built a proof of concept that illustrates how this problem could be used by an attacker to steal votes. Our proof of concept intercepts and manipulates votes cast to the practise server, though the same attack would also have succeeded against the real voting server. (We checked that the real site used the same vulnerable code, but, of course, we did not attempt to intercept or interfere with any real votes.) The attack works if a voter uses iVote from a malicious network–say, from a WiFi access point that has been infected by malware. In our demonstration, the malicious network injects code that stealthily substitutes a different vote of the attacker’s choosing. We also show how the attacker can steal the voter’s secret PIN and receipt number and send them, together with the voter’s secret ballot choices, to a remote monitoring server.

We demonstrated that an attacker could inject malicious code

The flaw could be used to compromise privacy and steal votes

We reported this vulnerability to CERT Australia at 2 p.m. Friday, and around noon the next day the Electoral Commission updated iVote to disable the code from piwikpro.com. Unfortunately, the system had already been operating insecurely for almost a week, exposing tens of thousands of votes to potential manipulation.

Although the vote submission site now uses SSL safely, the main gateway to it runs plain HTTP. This means that even with the FREAK vulnerability repaired, an attacker can still target voters before they reach the secure server using the classic ssl_strip attack.

Flawed verification

If the election is a close one, the only evidence that the results aren’t fraudulent may come from iVote’s verification and auditing process, but that process has its own share of problems.

iVote’s verification process is an optional step in which voters can dial a phone number and enter their iVote ID, PIN, and receipt number to hear a computer read back their ballot selections. Only a fraction of voters actually do this check, but, if enough votes are stolen with an attack like the one above, at least some voters should notice during verification and complain.

The attacker can use a variety of simple tricks to reduce the probability that a given voter will notice a problem. For example:

• Voters are instructed how to verify by the same vulnerable website, so the attacker could direct the voter to a fake verification phone number that would read back the voter’s intended choices. Thanks to modern VoIP technology, setting up an automated phone system is just a matter of software.
• The attacker can delay submitting the vote and displaying the receipt number for a few seconds, in hopes that the voter doesn’t intend to verify and simply leaves the website. (Perhaps the site could show a progress bar in place of the number.) If the voter navigates away, there’s no chance to verify, and the attacker submits a fraudulent vote. Otherwise, the attacker gives up, submits the voter’s genuine vote, and displays the receipt number.
• The verification phone number is scheduled to shut down immediately at the close of polls, even though there is sometimes a delay before votes become available to verify. An attack that focused on last-minute votes would be much harder to detect, since those votes can’t be verified.

The iVote verification design doesn’t provide strong evidence to support or disprove voter complaints, making it difficult to distinguish an attack from the baseline level of complaints due to voter error. Inevitably, some voters will falsely complain, either mistakenly or maliciously, and it’s hard to separate this from a genuine attack, particularly if the attacker only tries to steal a few percent of votes.

In addition to these problems, the verification design badly compromises privacy and exposes voters to possible coercion, since it makes it easy to prove how you voted to anyone just by handing over your credentials and receipt number. It also offers only weak security assurances against server-side attacks, since voters have to trust that the machine on the other end of the phone is honest.

It’s true that a properly designed and securely implemented verification system should detect fraud. But the source code and design details for the iVote servers and verification systems remain secret, so neither the security of the systems nor the validity of the protocols is well established. We’d like to be able to understand the verification system, server operation, and audit process in more detail. We can tell, by analyzing the client code, that the real system differs in important details from the descriptions in public documents, but we can’t rule out further important vulnerabilities without knowing precisely how verification and auditing work. Why should the public accept the election results when the method of counting and verifying their votes is a secret?

An unverifiable Internet voting system may seem to be secure but actually be subject to undetectable electoral fraud. In a way, iVote is worse: a system that seems to be verifiable but possibly isn’t.

Broader implications

Ordinary mistakes can have serious implications for elections. On the second day of voting, iVote was taken offline for several hours to correct an error in the online ballot form. Two political groups were omitted from part of the ballot, though their candidates’ names appeared elsewhere. The error was easy to fix, but 19,000 people had already voted.

The vulnerability to the FREAK attack illustrates once again why Internet Voting is hard to do securely. The system has been in development for years, but FREAK was announced only a couple of weeks before the election. Perhaps there wasn’t time to thoroughly retest the iVote system for exposure. We can bet that there are one or more major HTTPS vulnerabilities waiting to be discovered (and perhaps already known to sophisticated attackers). Verification is a vital safeguard against such unknown problems, but at best it detects problems rather than preventing them.

To election security researchers, these problems aren’t surprising. We’ve already seen dire security problems with Internet voting in Estonia and Washington, D.C. Securing Internet voting requires solving some of the hardest problems in computer security, and even the smallest mistakes can undermine the integrity of the election result. That’s why most experts agree that Internet voting cannot be adequately secured with current technology.

NSW should cut its losses and back away from voting online at least until there are fundamental advances in computer security. In the meantime, there’s another week of voting left–who knows what else could go wrong?

Update Mar. 23 1:30 PM AEDT — Our response to the NSWEC’s response

While we are pleased that the NSWEC rapidly made changes to iVote in response to our findings, we are concerned that they do not seem to understand the serious implications of this attack. Before the EC patched the system, the problem could be exploited under realistic and widespread conditions, and the iVote system cannot prove that this did not occur.

The problem was a direct consequence of faulty design in the iVote system, particularly the decision to include code from an external source. Its effect was to allow an attacker to modify votes, which shows the EC’s claim that the vote was “fully encrypted and safeguarded [and] can’t be tampered with” to be false.

We had to demonstrate a breach with the practice system because breaching the actual iVote process carries a penalty of three years in gaol, according to the EC’s website. Since the real system uses identical code, the real system would have been susceptible to the same attack.

The integrity of the election now relies on iVote’s verification and auditing processes, but these provide only limited defence, at best. The EC’s security testing failed to expose the vulnerability we found, and may have also missed flaws in the server software, verification protocol, and auditing process. The EC has so far declined to make these critical components available for public scrutiny.

Vanessa Teague is a research fellow in the Department of Computing and Information Systems at at the University of Melbourne. She specializes in electronic voting, with a focus on cryptographic schemes for end-to-end verifiable elections.

J. Alex Halderman is an assistant professor of computer science and engineering at the University of Michigan and director of Michigan’s Center for Computer Security and Society.