The below is an FAQ about our publication, The Ballot is Busted Before the Blockchain: A Security Analysis of Voatz, the First Internet Voting Application Used in U.S. Federal Elections
Is it true that this was done on an older version of the app?
The app we analyzed was the most recent version of the Android app as of January 14, 2020. We began our analysis in December, and reported to DHS’ Cybersecurity and Infrastructure Security Agency (CISA) in January. Around when we began our disclosure to CISA, Voatz submitted 4 new versions of the app to the Google Play store.
Nothing in the Voatz blog post has indicated how any of the later versions address the vulnerabilities we identify. Voatz was made aware of our findings over two weeks before publication. Voatz obfuscates its code, which makes it particularly difficult to review, so we have not repeated our efforts to de-obfuscate the code, as we did the first time. We encourage them to release the source code publicly, so that the security community can verify.
We otherwise have very little information on what they’ve changed in these four versions of the app. According to the APK Pure database, the “what’s new” notification (which is displayed to the user on update) for every version of the app since the version we analyzed in Google play are:
- Jan 15: v1.1.77 Minor improvements for accessibility and support for new elections.
- Jan 21: v1.1.83 Minor improvements for accessibility and support for new elections.
- Jan 25: v1.1.85 Minor improvements for accessibility and support for new elections.
- Jan 26: v1.1.87 Minor usability updates
There has been one additional version since Voatz received a summary of our findings from DHS on Jan 29:
- Feb 5: v1.1.90 Minor updates to UI, accessibility and translations
In a press call on Thursday Voatz CEO Nimit Sawhney said they fixed one of these vulnerabilities “many months ago.” That cannot be correct, as it was found in the most recent version available less than one month ago. There is no public evidence that they have patched any of the vulnerabilities identified, but we would certainly be interested in seeing it if they do.
Were you offered access to Voatz’s backend infrastructure or servers as part of this research?
We were not. We were aware of their bug bounty program on HackerOne, and in their response to our findings before publication, they directed us, through a document provided to us by DHS, back to the bug bounty program hosted on HackerOne. There are many reasons why we chose not to use the bug bounty.
Most crucially, many of the threats we wanted to research were outside of the scope of the bug bounty program. To quote the HackerOne page, “Attacks requiring MITM [Man In The Middle]” are completely out of scope. We wanted to assess any plausible attack on the application, and do not believe that a real-life attacker would exclude MITM attacks.
We did evaluate using the HackerOne program for some of the attacks, but the bug bounty version of the app did not function correctly. We attempted to use the bug bounty app on a supported, un-jailbroken, clean and fully patched install of Android, and it would fail to connect. A complete security evaluation requires the ability to reverse engineer the server code. Voatz provided no further resources to help a researcher emulate the server, such as a binary or source of the server, or a way to control or modify the server.
Voatz claims that the HackerOne version of the apps would give a correct picture of their live system performance, but we have no way of verifying that as all of the apps (including the versions hosted on HackerOne) were obfuscated. We had no way of knowing what differences existed between the non-live version and the deployed app. There is also no documentation as to the differences between the live application and the HackerOne version.
Is there anything Voatz could have placed on their server that would have stopped the attacks that you identify?
For the sake of the validity of our research, we assumed that they have properly deployed a blockchain, and that the blockchain is secure, monitored, and immutable. A key point of our findings is that none of those technologies secure the user’s vote during its transmission from the app to the Voatz server. At that stage the data is essentially standard web traffic, and thus susceptible to all of the attacks that standard web traffic can receive.
Voatz claimed on their press call that there existed other security features on the phone and/or the server that could have stopped these attacks. If they are referring to their use of the Zimperium antivirus, such features would only marginally increase the effort to execute these attacks, as we stated in § 5.1.1 of our report; host based IDS systems and antivirus solutions do not stand up to targeted attacks. Further, any security features should be subject to public scrutiny and assessment.
Nothing done by the server — e.g., printed receipts, emailed receipts, or the use of a blockchain — changes this analysis, because the tampering will occur before the vote reaches this part of the process. Attackers are able, through the exploits we describe, to manipulate the information that is recorded on the blockchain in just the same way as they can interfere with the ballot information itself. For example, in § 5.5 of the paper, we explain why such emailed receipts could be subject to tampering as well, and thus a voter could be sent a receipt saying they voted for one candidate, when their vote was cast for another.
Are previous “successful” elections proof of good security?
No. We have no way of knowing whether prior elections were successful, as an attacker could have concealed their attack. It is also possible that prior elections were too small to draw the attention of potential attackers. We don’t think the attacks would be difficult to pull off, especially given the amount of money spent in elections, the number of state and private actors who have a vested interest in manipulating elections, and the potential harm that could come from changing the outcome of an election.
Is it true that some of your attacks require physical access?
No, that this is a mischaracterization of the work and results. All an attacker needs to do is obtain root control over a device. This could be done through physical access, but it could also be done through remote exploitation of the operating system.
At the time of writing, local privilege escalation from an untrusted app to root control over the device in either Android or iOS, costs $200,000 (see here). Assuming even an ten-fold increase in this number for operationalization, this sum is still well within the means of any sophisticated actor.
Why did you report your findings to CISA instead of Voatz? Why did you stay anonymous during the responsible disclosure process?
We agree with Voatz that election systems are “critical infrastructure” as designated under DHS’s guidelines. So, we reported to CISA, as the agency responsible for securing such infrastructure. Through CISA we were able to notify both Voatz and the affected states’ election officials, while also protecting us and our research. We wanted the research to speak for itself, and had legal concerns about Voatz’s unprofessional response to prior independent security research, as has been documented in multiple news outlets.
What do you recommend for next steps here?
We agree with Voatz that it is important to improve election accessibility, particularly for disabled people, the elderly, military and overseas voters. We disagree, however, that we should subject these populations to experiments that risk the safety, security, and integrity of their vote. We should not test unproven, unreliable voting technologies on people who deserve better accessibility options. All Americans deserve secure and reliable elections.
We therefore recommend that elections officials abandon the app for immediate use, and require that all future critical voting infrastructure be made open source, transparent, and subject to public, independent audit.