Why Hard-Coded Credentials Still Own the Voting Machine Ecosystem

TLDR: The California Top-to-Bottom Review and Ohio EVEREST study exposed critical security failures in electronic voting systems, specifically the reliance on hard-coded credentials and lack of independent security testing. These systems, often running legacy OS versions like Windows CE or Windows 2000, remain vulnerable to trivial exploitation by anyone with physical access. Security researchers must prioritize auditing these systems for identification and authentication failures to prevent unauthorized access to critical election infrastructure.

Security researchers often get distracted by the latest zero-day in a cloud-native framework or a complex chain of vulnerabilities in a web application. While those are important, the most dangerous vulnerabilities are often the ones that have been sitting in plain sight for decades. The California Top-to-Bottom Review and the subsequent Ohio EVEREST study serve as a stark reminder that critical public infrastructure is often built on a foundation of security debt. When we talk about voting machines, we are not talking about mysterious black boxes. We are talking about desktop PCs running outdated, unpatched operating systems like Windows CE or Windows 2000.

The Reality of Legacy Hardware and Hard-Coded Secrets

The core issue identified in these studies is the complete lack of modern security controls. During the review, researchers found that vendors frequently hard-coded administrative passwords directly into the system binaries. In one instance, a simple strings analysis of the binary revealed a password, accompanied by a developer comment explicitly stating the password was hard-coded to prevent hackers from using it. This is a classic example of security through obscurity failing in the most predictable way possible.

For a pentester, this is low-hanging fruit. If you gain physical access to these machines, you are not looking for complex buffer overflows. You are looking for the default or hard-coded credentials that grant you full administrative control over the election management system. Once you have those, you can manipulate ballot definitions, alter tally data, or deploy custom malware to ensure persistence across future elections.

The attack flow is straightforward:

1. Physical Access: Gain access to the voting machine or the election management system.
2. Credential Extraction: Use basic tools like strings to extract hard-coded passwords from the system binaries.
3. Authentication: Use the extracted credentials to authenticate as an administrator.
4. System Manipulation: Modify the ballot design or tally software to influence election outcomes.

Why Software Independence is the Only Path Forward

The fundamental problem with these systems is that they lack software independence. A system is software-independent if an undetected change or error in its software cannot cause an undetectable change or error in the election outcome. In the systems analyzed, the software was the single point of failure. If the software was compromised, the entire election was compromised.

This is why the push for software independence is so critical. We need systems where the integrity of the vote can be verified independently of the software running on the machine. This means moving away from systems that rely solely on electronic records and toward systems that provide a voter-verifiable paper audit trail.

The Danger of Vendor Capture

One of the most frustrating aspects of this research is the degree of vendor capture. Election officials, often lacking the technical expertise to evaluate these systems, rely entirely on the vendors for training, certification, and maintenance. This creates a dangerous feedback loop where the vendor dictates the security standards, and the officials are left with no way to independently verify the security of the systems they are using.

When we see systems that are not designed with security in mind, we see the results of this capture. The lack of independent security testing, the reliance on proprietary and undocumented protocols, and the refusal to allow third-party researchers to audit the code are all symptoms of a system that prioritizes vendor convenience over public trust.

What Pentesters and Researchers Should Do

If you are a security researcher or a pentester, you have a role to play here. We need more eyes on these systems. We need to push for transparency and independent audits. When you are on an engagement that involves critical infrastructure, do not just look for the latest CVEs. Look for the architectural flaws. Look for the hard-coded credentials. Look for the ways in which the system fails to provide an independent audit trail.

The goal is not to prove that these systems are broken. We already know they are broken. The goal is to force a change in the way these systems are designed, certified, and maintained. We need to move toward a model where security is not an afterthought, but a core requirement of the design process. We need to demand that these systems be built with the assumption that the software will be buggy, and that the only way to ensure the integrity of the election is to build a system that is resilient to those bugs.

The next time you find yourself looking at a piece of critical infrastructure, ask yourself: if this system were compromised, would we even know? If the answer is no, then you have found the most important vulnerability of all. Keep digging, keep reporting, and keep pushing for the transparency that our democratic processes deserve.