Voatz ‘Blockchain’ App Used in US Elections Has Numerous Security Issues, Says Report

An audit report of Voatz platform confirms numerous issues previously discovered, and the voting app declines to make all the necessary changes.

Voatz, the Massachusetts-based company touting a blockchain-enabled mobile voting app, has been met with public criticism for a lack of transparency, among other things, particularly when it comes to data security. And with the threat of election tampering, the stakes are as high as ever.

Voatz has been used in elections in West Virginia; Jackson County, Oregon; Umatilla County, Oregon; municipal elections in Utah County, Utah; as well as in runoff elections and municipal elections in Denver, Colorado.

The public security audit by a reputable third-party firm that experts have been calling for is here at last. In December 2019, Voatz and Tusk Philanthropies, which funded most of Voatz’s mobile voting pilots, engaged security firm Trail of Bits to conduct a comprehensive white box audit.

Although Voatz failed to provide a backend to live-test malicious attack vectors, Trail of Bits had access to all of the source code, including the core server, Android client, iOS client and administrator web interface.

The audit report is comprehensive, and includes a 122-page security review and a 78-page document on threat-modeling considerations. Here’s a quick rundown of the main parts.

Voatz doesn’t need blockchain 

The appeal of blockchain voting is that it’s a decentralized system that doesn’t require voters to trust anybody. But the blockchain Voatz uses doesn’t actually extend to the mobile client. Instead, Voatz has been applying the votes to a Hyperledger Fabric blockchain, which it uses as an audit log — something just as easily done by using a database with an audit log.

Although a Voatz spokesperson claimed that Hyperledger “provides several security functions such as securing the aggregate vote, enabling post election auditing and providing a chain of custody for the digital ballots as they traverse through the ecosystem,” it’s unclear how it would do so, and this capability isn’t evident in the report.

The code Trail of Bits looked at did not use custom chaincode or smart contracts. In fact, the report reads:

“All data validation and business logic are executed off-chain in the Scala codebase of the Voatz Core Server. Several high-risk findings were the result of data validation issues and confused deputies in the core server that could allow one voter to masquerade as another before even touching the blockchain.”

Because voters do not connect directly to the blockchain themselves, they can’t independently verify that the votes reflect their intent. But anyone with administrative access to Voatz’s back-end servers has the ability to “deanonymize votes, deny votes, alter votes, and invalidate audit trails.”

The report found that the Voatz system doesn’t have any mitigation for deanonymizing voters based on the time their ballot was recorded in the blockchain. In a statement, a spokesperson for Voatz said it had an experimental mixnet running at the edge-infrastructure used for network level experiments, but without any source code, and Voatz’s FAQ claims that “once submitted, all information is anonymized, routed via a ‘mixnet’ and posted to the blockchain.” But this was called into question in an MIT report — and now again in this audit.

“There does not appear to be, nor is there mention of, a mixnet in the code provided to Trail of Bits,” the audit reads. “The core server has the capability to deanonymize all traffic, including ballots.”

Trail of Bits confirmed MIT’s findings — Voatz disputed them

On Feb. 13, MIT researchers published the aforementioned report, “The Ballot Is Busted Before the Blockchain: A Security Analysis of Voatz, the First Internet Voting Application Used in U.S. Federal Elections,” to which Voatz responded with a blog post the same day to refute what it called a “flawed report,” leading the MIT researchers to post an FAQ with clarifications.

It turns out that Voatz’s refutation was written three days after Trail of Bits confirmed the presence of the described vulnerabilities to MIT, having received an anonymized summary report of the issues from the United States Department of Homeland Security. This suggests that Voatz was aware that the report was accurate before publicly discounting it.

The audit also disputes some of Voatz’s objections to the MIT researchers’ reports. Voatz stated that the Android app analyzed was 27 versions old, but Trail of Bits wrote that it “did not identify any security relevant changes in the codebase” between the September 2019 version of the app used by the MIT researchers that would substantively affect their claims. 

Voatz also took issue with the researchers developing a mock server, calling it a “flawed approach” that “invalidates any claims about their ability to compromise the overall system.” Voatz even wrote that this practice “negates any degree of credibility on behalf of the researchers.” 

But Trail of Bits claims that “developing a mock server in instances where connecting to a production server might result in legal action is a standard practice in vulnerability research. It is also a standard practice in software testing.” Furthermore, the report points out that the findings focused on the Android client, but did not rely on in-depth knowledge of the Voatz servers.

A Voatz spokesperson says Voatz “objects to the methodology and approach of the MIT researchers,” and that there are “several errors in the report.”

“If our methodology was wrong, the theory would be that we would come to incorrect conclusions. However, all of the vulnerabilities we found have been confirmed by their own security review. Additionally, it doesn’t appear that they’re contesting any of them,” said Michael Specter, one of the MIT researchers who authored the report.

Prior audits were not comprehensive

Despite Voatz touting multiple security audits, this is the first time a white box assessment has been conducted, with the core server and backend having been analyzed. Although not all of the prior audits are public, Trail of Bits summarized all of them.

One prior security review was conducted in August 2019 by NCC, an independent, private nonprofit that doesn’t employ any technical security experts. The audit focused on usability rather than security. In July 2018, an unnamed vendor conducted a black box audit of Voatz’s mobile clients. 

In October 2018, TLDR Security, now known as ShiftState, conducted a broad security hygiene review that included system architecture, user and data workflows and threat mitigation planning, but didn’t look for bugs in the system nor in the actual application. ShiftState then conducted another audit in December 2018, looking at whether the system operated as intended and followed best practices.

Although ShiftState CEO Andre McGregor has previously said that Voatz “did very well,” Trail of Bits’ review of ShiftState’s audit points to issues with limited logging, unmanaged servers and a Zimperium anti-mobile malware solution that wasn’t enabled during the pilot. 

Since all of Voatz’s anti-tamper protections for mobile devices are based on Zimperium, it being inactive means the application could have been trivially tampered with, as Voatz lacks additional protection against malicious applications that could access sensitive information.

A Voatz spokesperson said that Zimperium wasn’t fully integrated until 2019 and that some researchers request its disablement for testing purposes, which they do on a case-by-case basis. “Trail of Bits could not independently verify that Zimperium’s proprietary anti-tamper checks explicitly verify the Android security provider,” the report reads, recommending an additional check in case Zimperium is ever disabled, intentionally or not. 

The final audit by the DHS, conducted in October 2019, simply looked at cloud resources, not at the application — whether there’s evidence of hacking or if it could be detected if it takes place.

Beyond the limitations of prior security assessments that Voatz has touted without making public — such as the fact that none of the audits included server and back-end vulnerabilities — Trail of Bits’ report states that the writeups from the other security assessments conducted were technical documents. This calls into question whether elected officials are making decisions based on documents they’re unqualified to read.

Voatz appears wildly disorganized

Trail of Bits’ assessment lasted an entire week longer than initially scheduled “due to a combination of delays in receiving code and assets, the unexpected complexity and size of the system, and the associated reporting effort.”

Trail of Bits never received a working copy of the code, prohibiting the firm from live-testing, meaning that the researchers were almost entirely limited to static-testing, which required them to read through a massive amount of code. According to the report, Voatz has so much code that it “required each engineer to analyze, on average, almost 3,000 pure lines of code across 35 files per day of the assessment in order to achieve minimal coverage.”

Although Trail of Bits received access to the backend for live-testing a day before the assessment was scheduled to end, —which a Voatz spokesperson said was due to simultaneous audits, delays in audits and parallel activities, and a limited amount of test platforms, the security firm was asked not to attack or alter the instance in a way that would deny service to concurrent audits.

Voatz made rookie mistakes — and doesn’t seem serious about fixes

Trail of Bits described several bugs that could lead to votes being observed, tampered with or deanonymized, or that could call the integrity of an election into question.

Beyond the fact that voters can’t independently validate that their ballot receipt is valid or that votes were tallied correctly, a Voatz employee could theoretically force a user to vote twice, allow them to vote twice or duplicate their vote without their knowledge on the backend. Also, Voatz uses an eight-digit PIN to encrypt all local data — something that could be cracked within 15 minutes.

Furthermore, the report found that the app doesn’t have security controls to prevent unattended Android devices from being compromised. Sensitive API credentials were stored in git repositories, which means anyone in the company with access to the code — perhaps even subcontractors — could use or abuse secret keys exposed in the repositories.

Voatz employees with admin access can look up specific voters’ ballots. Voatz uses an ad hoc cryptographic handshake protocol, which is generally not recommended — as homemade cryptography is prone to bugs, and it’s best to use encryption schemes that have been studied by researchers and tested out in the real world. The SSL (Secure Sockets Layer) wasn’t configured in an entirely secure way, missing a key feature that helps clients identify when a TLS (Transport Layer Security) certificate is revoked.

In one instance, Voatz even cut and pasted a key and initialization vector from a Stack Overflow answer. Cutting and pasting code is generally discouraged, even in college-level computer security courses, because the quality of information on Stack Overflow varies, and even good code might not work in a specific environment. However, cutting and pasting a key and IV is even worse, as it means that the key and IV used to encrypt the data are identical to something on the internet, even though it is not supposed to be public. A Voatz spokesperson said in an email that this was test-code for an in-app demo and “was not actually used in any case or transaction.”

Even when summarized, Trail of Bits’ recommendations are eight pages long. Voatz appears to have addressed eight security risks, partially addressed another six, and left 34 unfixed. Typically, companies have a comprehensive plan on how to fix high and medium risks. Indeed, a spokesperson for Voatz said, “We take each finding seriously, analyze each finding from a practical perspective, assign the probability of risk and then determine the course forward,” a Voatz spokesperson said in an email.

“If the bug or issue is practically exploitable in a real world scenario conforming to the small scale pilots we are conducting, then we address them immediately else they flow in our normal development pipelines subject to priorities.”

Shockingly, Voatz decided it “accepts the risk” of many of these bugs, essentially accepting risk on behalf of the voters rather than making the fixes suggested from the firm it hired.

Tusk Philanthropies, Voatz and Trail of Bits referred Cointelegraph to their separate blog posts about the audit, and Trail of Bits referred to the report itself.

This article has been updated with comments by a Voatz spokesperson.

Related: Safe Harbor or Thrown to the Sharks by Voatz?