Iowa Caucus App: What Should We Do about It Now?

In February, during the 2020 Iowa Democratic caucuses, usage of a mobile application called IowaReporterApp, which had been created to facilitate and speed up votes counting, resulted in a multi-day delay in final votes counting and affected the trustworthiness of the results. The application was created and operated by a company named Shadow Inc. CEO Gerard Niemira later issued an apology:

So, what actually happened, and what can we learn from this? Syberry specialists were able to get their hands on the application itself to make their own conclusions.

The Application

The IowaReporterApp is a mobile application, built using React Native mobile application framework to facilitate its execution on both iOS and Android platforms. Anyone interested can check meta- information and signatures for the application in the VirusTotal database.

When launched, a login screen is presented:

Picture 1. Login screen of the application.

For practical purposes, therefore, our further analysis was limited to static code review. While it is likely that the application may contain potentially exploitable vulnerabilities allowing some form of Man-in-the-Middle attacks, and many were quick to blame the developer for that, it is important to note that based on our review, it is unlikely that a third-party was able to affect actual votes. Our specialists were unable to locate any hard-coded credentials in the source code that might have allowed elevated access to the voting data, and encrypted (https) communications were used to submit the data. It was potentially possible for someone to disrupt the vote counting process by submitting duplicate data (resulting in some form of the Denial of Service attack), but it would be unlikely for a malicious actor to actually change submitted votes without revealing the attack itself and triggering a recount. (Note that this statement assumes reasonable quality control checks were implemented before declaring the final results).

What is more important in our opinion is this portion of the Shadow Inc. CEO’s statement: “…the underlying data and collection process via Shadow's mobile caucus app was sound and accurate, but our process to transmit that caucus results data generated via the app to the IDP was not.” That implies that operation of the back-end infrastructure required for the mobile application to work was also created by Shadow Inc Company, and that employees of the Company were actually in position to amend or correct voting counts if they decided to do so.

The Company

Shadow Inc.’s LinkedIn profile provides a high-level idea of the company behind the application. As of mid-February, there are eight (8) total employees of the company, with the following titles:

1. Director of Product (New York City)
2. Chief Technical Officer (Seattle)
3. Chief Executive Officer (Denver)
4. Chief Operations Officer (New York City)
5. Junior Frontend Developer (Denver)
6. Junior Frontend Developer (New York City)
7. Client Success (Iowa City)
8. Director of Organizing and Client Success (Iowa City)

There are only two junior engineering positions and not a single senior engineering role (except for CTO) or quality assurance role. Analysis of the digital footprints indicate that source code of the application was stored on computers with users having the following names:

1. jameshickey - COO of the Company
2. satya - No LinkedIn profile found for an employee with name

The user ‘satya’ quite likely contributed majority of the code for the application. If this person is an employee, he decided not to publish his workplace on LinkedIn. An alternative explanation could be that Shadow Inc. outsourced the development to another company or contractor.

Management of the company appears to be linked to Hillary Clinton’s 2016 campaign, as well.

The Party

As reported by CNN, the Democratic Party’s official position in regards to the application is, “We did not build the application, nor did we provide 'oversight' of its development—that’s the vendor’s responsibility. We only provided security assistance."

It appears the Democratic Party relied on the Shadow Inc.’s expertise to build a secure application without any oversight. As the software industry has learned the hard way, security may not be achieved just through a third-party audit (and there is no indication that any security audit was even performed before using the application in Iowa). You have to select a vendor who knows how to build secure software, especially if you can be attacked by the most sophisticated, state-sponsored hacker teams on earth. Just requiring an application to be secure in a contract will not make it happen automatically. Moreover, given the importance of the voting data, it is a standard security practice to separate the people creating the Software (Shadow Inc. in this case) from people operating and accessing actual voting data (by either having your own team in-house or using another company to operate the software). Just assuming that this is “the vendor’s responsibility” implies a lack of understanding of how secure software can be built and operated. This, in turn, leads to a probable root cause of the whole situation: lack of software and security expertise sufficient to use modern technologies in the first place. In other words, lack of a qualified Chief Technology Officer who can drive and securely implement technology initiatives in the twenty-first century.

Learning from Mistakes

We would recommend that the Democratic Party implement the following plan:

1. Publish source code of the IowaReporterApp.

   While binaries of the application are available to the public, the Party should publish its source code for independent audit by anyone. This will help restore the trust and allow the public to validate the Shadow Inc. CEO’s statement that “the underlying data and collection process via Shadow's mobile caucus app was sound and accurate.”

2. Explain the process of selecting Shadow Inc. as the software vendor.

   There is likely no “good” answer why the company was selected, but if there is, there is no reason to hide it. Regardless, admitting the mistake of not selecting the vendor properly (if that was the case) or presenting the evidence why it was the right choice will re-establish trust in the Party’s use of the software.

3. Publish results of a security audit performed by a Party-appointed third party.

   If any security audit was performed, the Party should present the results as the evidence that they “take the security very seriously.”

4. In the future, do not use the same company to build and operate your applications.

   It is a well-known security practice to separate the teams responsible for building and operating your technologies. In fact, we recommend building a voting infrastructure where collected data can be submitted for more than one auditing entity for processing. This will reduce probability of meddling by the team operating the production infrastructure itself.

5. Use open source software for all voting needs.

   People familiar with software security are aware that “security by obscurity” is a bad practice and will not stop a qualified third-party from hacking the software. In fact, the opposite is true: while malicious actors will still be able to hack non-open source software, the ability to detect and report errors in such software will be limited.

   However, by the Party’s own admission, the concept is misunderstood, and the Party wrongly believes that keeping technology used in the voting process a secret has security benefits, as referenced in the above-linked Wikipedia article:

   “In January 2020, NPR reported that party officials in Iowa declined to share information regarding the security of its caucus app, to ‘make sure we are not relaying information that could be used against us.’ Cybersecurity experts replied that ‘to withhold the technical details of its app doesn't do much to protect the system.’”

   Now, even using a qualified third-party like Microsoft (suggested by some) is not good enough as it limits public ability to audit, detect, and potentially correct errors in the software. Instead, the Party should start using open source software, which will allow a wider community of software engineers to contribute to the security of the voting process. Both Parties should ideally use the same open source software, as they will benefit from collective expertise of the open source community as far as security is concerned.

6. Hire a competent chief technology officer.

   If the Party already had a CTO, it would appear he or she showed poor judgment in this instance. The Party officials have demonstrated that they lack very basic understanding of what makes modern software secure, and therefore the very first task for the CTO would be to establish a proper IT security education program, as well as establish basic operating rules. Hiring a qualified person (at least one) will also show the public that the Party takes security seriously.

Iowa Caucus 2016

After completing our analysis, we learned that both parties successfully used a different technology in Iowa during the 2016 election! Microsoft published the success story, including insights from representatives of both parties.

The technology was built and tested in advance, and the project took approximately a year to complete. It was possible to reuse the same technology, probably with very minor modifications. So why make the change? That will probably remain a mystery.