Security Risks of Mail In Voting

The Security Risks Behind Voting Machines & Mail-in Ballots

In recent months, the security of absentee voting, widely used due to the threat of the COVID-19 pandemic, has been called into question. But are these processes any less secure than the electronic voting systems used on a “normal” election day?

Is Mail-In Voting Safe?

Introduction to Electronic Voting System Security

Electronic voting systems come in a number of different forms. At the polls, a voter may experience a few different types of voting systems:

  • Paper Ballots: Paper ballot systems have voters fill out ballots by hand with paper and pens/pencils or hole punches. These ballots may then be scanned in order to rapidly tally votes.
  • Electronic Systems: Purely electronic systems allow voters to vote on a touchscreen computer. In some states, votes are only stored and tallied electronically with no backups.
  • Hybrid Systems: Some systems will allow voters to cast votes with a touchscreen, then print a paper ballot for them to verify. This leaves a paper trail of their choices, however, a study indicated that 94% of voters didn’t notice that their votes had been changed.

Known Security Issues of Electronic Voting Systems

Electronic voting machines have a number of different security issues, many of them known for over a decade. The issues with electronic voting and the challenges of fixing them have been demonstrated by a number of different cases, including:

  • Insecure Voting Machines: An assessment of the security of over 100 voting machines at the 2019 DEFCON conference found that all of them contained exploitable vulnerabilities, including weak default passwords, built-in backdoors, etc.
  • Lack of Support for Penetration Testing: Security assessments of voting machines are limited by a lack of manufacturer support, and interpretations of the Computer Fraud and Abuse Act that make such assessments illegal. An amicus brief to the Supreme Court regarding the case advocated for limiting security research to researchers authorized by the company under test, enabling the company to conceal any findings.
  • Use of Outdated Software: A survey completed in July and August 2019 of 56 election commissions and Secretaries of state found that over half of voting systems in use ran Windows Server r2 2008, which reached end-of-life January 14, 2020.

These issues point to the conclusion that a determined attacker could easily breach the US election infrastructure if they chose to do so. The fact that this has not occurred is attributed to the fact that no threat actor has chosen to do so. In fact, Russia is believed to have gained access to voter registration systems in several states in 2016 but chose not to take action on it.

However, this lack of discovered breaches may have resulted from a lack of looking for them. In 2018, Netragard performed an analysis of the Crosscheck system designed to detect voters casting multiple ballots in different jurisdictions. Based upon analysis of public information, several vulnerabilities were discovered, but they could not be followed up on because hacking election infrastructure is illegal.

After hearing of the assessment, a Kansas official claimed that our team “didn’t succeed in hacking it.” Later a different claim by another Kansas legislator claimed that a “complete scan” did not find any evidence of attackers exploiting the vulnerabilities to breach the system. This is despite the fact that no vulnerability scan could detect a breach and that no evidence exists of a digital forensics investigation occurring to identify a potential breach.

At the end of the day, the answer to the question of whether or not a hacker could breach US election infrastructure is “almost certainly”. However, no evidence exists of this occurring, potentially because no conclusive investigation has been performed.

Introduction to Mail-In Ballot Security

In most states, voting via an absentee or mail-in ballot is a two step-process. The first step is submitting an absentee ballot request. If this request is validated, an absentee ballot is sent to the voter’s registered address to be completed and returned via mail or an election dropbox.

The validation steps for absentee ballot requests and ballots vary from state to state. Each state performs at least one (and often several) of the following checks:

  • Envelope Verification: A ballot is only valid if returned in the official envelope. All ballots returned in a different envelope are discarded.
  • Signature Verification: Many states require a signed affidavit by the voter, and, in some states, election officials compare the signatures on the ballot and on a voter’s official registration. Mismatched signatures are the most common method by which voter fraud is detected.
  • Voter Identification: Many states will require a voter to submit some form of identification with their ballot, such as a photocopy of their driver’s license or part of their Social Security Number (SSN).
  • Witness Signature: Some states require the signatures of one or more witnesses or a public notary on a mail-in ballot.

Known Security Issues of Mail-In Ballots

The Heritage Foundation keeps a record of every case of alleged voter fraud that has been reported to date. This database includes a variety of different voting crimes, including fraudulent registrations, misuse of absentee voting, coercion of voters at the polls, and more. To date the Heritage Foundation has recorded 1,298 cases of alleged voter fraud between 1988 and 2020, though some of its claims are unsupported or incorrect.

Of these 1,298 cases, the Heritage Foundation claims that 207 individuals have been involved in 153 distinct cases of voter fraud that involved the use of absentee ballots. Of these cases, 39 (involving 66 individuals) have included a deliberate attempt to change the results of an election. Other cases involve people voting for a recently deceased spouse or relative, a single person voting twice in different jurisdictions, using a previous mailing address on a ballot, mailing in the ballot of a non-relative (which is illegal in many jurisdictions), and other small-scale errors or attempts at fraud.

In general, attempts to change the results of an election via mail-in voter fraud have focused on local elections with a small margin. One of the larger cases of fraud on record (Miguel Hernandez, 2017) involved an individual forging absentee ballot requests and collecting and mailing the ballots after the voters had completed them. This incident included only 700 mail-in votes, and the actual voting was performed by the authorized voters. Even if Hernandez forged the votes, the impact on a US Presidential election would be negligible.

For comparison, over 125 million votes were cast in the 2016 election. According to the Heritage Foundation, there were six attempts at absentee ballot fraud in the 2016 Presidential Election:

  • Audrey Cook voted on behalf of deceased husband
  • Steven Curtis (head of Colorado Republican Party) forged his wife’s signature on her ballot
  • Terri Lynn Rote tried to vote twice due to her fear that the election was rigged
  • Marjory Gale voted for herself and her daughter who was away at college
  • Randy Allen Jumper voted twice in two different jurisdictions
  • Bret Warren stole and submitted five absentee ballots that voters complained about never receiving and were allowed to cast provisional ballots

These cases are clear examples of voter fraud in the 2016 election. However, even if they were undetected and all voted the same way, ten votes are unlikely to have any impact on the election. In fact, an election commission looked into the claims of 3-5 million fraudulent votes being cast in the 2016 election. Claims were was disbanded with no findings.

Comparing Electronic Voting Systems and Mail-In Ballot Security

At the end of the day, there is no evidence of election interference or voter fraud using electronic voting machines or mail-in ballots. While six counts of misuse of absentee ballots were detected in the 2016 Presidential election, they comprised a total of ten votes.

If anything, the threat of glitches in electronic voting machines should be considered a major threat to election security. In 2019, analysis of the paper record of a “glitchy” voting machine led to the discovery that in a local Pennsylvania election, a candidate who only had 15 recorded votes actually won the election by over 1,000.

While mail-in ballots have their issues (like an overburdened postal system), electronic voting machines are much less secure and reliable. The fact that an unknown number of electronic voting systems are connected to the Internet, making them accessible to hackers and vulnerable to malware, creates a much greater exposure to election meddlers than absentee ballots, which must be physically collected and filled out to be used in fraud.

Inside the 2020 Ping of Death Vulnerability

What is the 2020 Ping of Death?

Ping of Death vulnerabilities are nothing new. These vulnerabilities arise from issues in memory allocation in the TCP/IP stack. If memory is improperly allocated and managed, a buffer overflow vulnerability can be created that leaves the application vulnerable to exploitation.

The original Ping of Death was discovered in 1997 and was the result of an implementation error in how operating systems handled IPv4 ICMP packets.    ICMP ECHO_REQUEST packets (aka ping) are intended to be 64 bytes, but this length was not enforced. Any ping packet with a length greater than 65536 bytes (the expected maximum value of the length field) would cause a system to crash.

In August 2011, Microsoft fixed another Denial of Service in its TCP/IP Stack that occurred when processing a sequence of specially crafted Internet Control Message Protocol (ICMP) messages

In August 2013, a third ping of death vulnerability was announced and patched in the Windows operating system. This time it was specific to the IPv6 protocol.

Yesterday (October 2020), Microsoft revealed its second IPv6 Ping of Death vulnerability as part of its October Patch Tuesday release. Exploitation of this vulnerability could allow an attacker to perform a Denial of Service attack against an application and potentially achieve remote code execution.

Inside the 2020 Ping of Death Vulnerability

2020 Ping of Death Technical Details

The Ping of Death vulnerability arises from an issue in how Microsoft’s tcpip.sys implements the Recursive DNS Server (RDNSS) option in IPv6 router advertisement packets. This option is intended to provide a list of available recursive DNS servers.

The issue that creates the Ping of Death vulnerability is that tcpip.sys does not properly handle the possibility that the router advertisement packet contains more data than it should. Microsoft’s implementation trusts the length field in the packet and allocates memory accordingly on the stack.

An unsafe copy of data into this allocated buffer creates the potential for a buffer overflow attack. This enables the attacker to overwrite other variables on the stack, including control flow information such as the program’s return address.

How the Vulnerability Can Be Exploited

In theory, the buffer overflow vulnerability can be exploited to achieve a couple of different goals:

  1. Denial of Service: Exploitation of the buffer overflow vulnerability enables “stack smashing” that can crash the application.
  2. Remote Code Execution: Using return-oriented programming, a buffer overflow exploit could cause a function to return to and execute attacker-provided shellcode.

In practice, a Denial of Service attack is the most likely use for this exploit. In order to perform a successful Denial of Service attack, all an attacker needs to do is attempt to write outside of the memory accessible to it (triggering a segmentation fault) or to overwrite a critical value within the program stack.

One of these key values is the stack canary, which is also one of the reasons why exploitation of this vulnerability is unlikely to allow RCE. A stack canary is a random value placed on the stack that is designed to detect attempts to overwrite the function return address via a buffer overflow attack. Before attempting to return from a function (by going to the location indicated by the return address), a protected program checks to see if the value of the stack canary is correct. If so, execution continues. If not, the program is terminated.

The existence of a stack canary makes it more difficult to exploit the vulnerability for RCE, and the use of Address Space Layout Randomization (ASLR), which makes functions useful to attackers harder to locate in memory, exacerbates this issue. However, it is possible to bypass both of these protections in certain cases, so an exploit may be developed that enables the 2020 version of the ping of death to be used for RCE. If this is the case, the repercussions could be severe as tcpip.sys is a kernel-level module within the Windows operating system.

Ping of Death in the Wild

A patch for this vulnerability was included in the October 2020 Patch Tuesday release of updates. At the time, the vulnerability was not publicly disclosed, meaning that (theoretically) no one knew about it previously and could develop an exploit.

Based on the Microsoft description of the vulnerability, a Proof of Concept for using it for a DoS attack has already been created. Additionally, the vulnerability has been given an exploitability value of 1, meaning that it is very likely to be exploited but has not yet been observed in the wild.

This means that we can expect to see DoS attacks using this vulnerability shortly, and the potential exists that an attacker will successfully create a RCE exploit using it as well. If this is the case, the wormability of the exploit makes it likely to be used to spread ransomware and similar malware (like Wannacry and EternalBlue).

Protecting Against the 2020 Ping of Death

The vulnerability in tcpip.sys was patched in an update included in the October 2020 Patch Tuesday release. Installing this update will fix the vulnerability and protect a system from exploitation.

Beyond installing the update, it is a good idea to minimize your attack surface by disabling unnecessary functionality. If you currently do not use the functionality, then disabling IPv6 in general or RDNSS in particular can eliminate the potential exploitability of this and any other vulnerabilities within the Microsoft implementation of this functionality. Instructions for doing so are included in Microsoft’s description of the vulnerability.

Inside Zerologon

What is the Zerologon Vulnerability?

Zerologon is a vulnerability in the Windows netlogon protocol (on Windows Server version 2008 and later) discovered by Tom Tervoort of Secura during a security review of the protocol (which had not previously undergone such a review).  Due to cryptographic and implementation errors in the protocol, an attacker can falsely authenticate and elevate their privileges to Domain Admin.  This has a number of potential impacts including:

  • Full Network Control: With Domain Administrator access, the attacker has full control over the network.
  • Credential Compromise: Netlogon enables an attacker to extract user account credentials for offline password cracking.
  • Credential Stuffing: Passwords compromised via netlogon are likely to be used on other accounts, enabling an attacker to access bank accounts, social media, etc.
  • Initial Access: With the access provided by netlogon, an attacker could steal sensitive data, deploy ransomware, etc.
  • Denial of Service Attack: Zerologon enables an attacker to change a password in Active Directory but not in the registry or LSASS.  This means that services on a rebooted machine may no longer function.

Technical Details of Zerologon

Zerologon exploits a vulnerability in the netlogon authentication process, which is performed as follows:

  1. Server and client each generate and exchange a random 8-byte challenge
  2. The shared session key is generated as the first sixteen bytes of SHA256(MD4(domain password),challenges)
  3. Client verifies the session key by encrypting and sending the original challenge that they generated encrypted with the new session key.

The zerologon vulnerability arises due to the fact that Windows netlogon uses an insecure variant of the cipher feedback (CFB) block cipher mode of operation with AES.

Normally, CFB mode is designed to encrypt 16-byte chunks of the plaintext (as shown above).  This enables the encryption or decryption of data longer than the standard 16-byte AES block size.  It starts by taking a random initialization vector, encrypting it, and XORing it with the plaintext of a block to create the ciphertext for that block.  This ciphertext is used as the input to encryption for the next block, and so on.

Zerologon

(via Secura)

The vulnerable version of CFB mode used in Windows netlogon (called CFB8) performs encryption one byte at a time.  To do so, it takes the following steps:

  1. The initialization vector (yellow) is encrypted using AES
  2. The first byte of the result (pink) is XORed with the first byte of plaintext (blue)
  3. The resulting byte of ciphertext is appended to the end of the IV
  4. The first byte of the IV is dropped
    1. The result is the same length as the original IV (yellow and pink above)
  5. Steps 1-4 are repeated until the entire plaintext is encrypted

While the use of a non-standard encryption algorithm is bad enough, the netlogon protocol made another critical error.  The initialization vector is hard-coded to zero, not random like it should be.

This creates a vulnerability if the first byte of encryption produces a ciphertext byte of zero (which occurs with 1/256 probability).  If this is the case, then the result of encryption will always be all zeros.  This is because the input to the encryption algorithm will always be the same (since the IV is all zeros and the value appended to the end during each round of encryption is a zero).

This makes it possible for an attacker to authenticate via netlogon with no knowledge of the domain password.  By trying to authenticate repeatedly to the system with an all-zero challenge, the attacker can trigger the 1/256 chance that the shared secret (that they don’t know) encrypts the first byte of the challenge to a zero.  They can then trivially generate the encrypted challenge (step 3 in the netlogon authentication process) since it is all zeros.

How Zerologon Can Be Exploited

The Zerologon vulnerability, by itself, only enables an attacker to successfully authenticate to the domain controller and encrypt all-zero plaintexts.  However, this is enough to successfully call the NetrServerPasswordSet2 function, which is designed to change the server password.  This function takes the following parameters:

  • Original client challenge plus the current time in POSIX notation
  • Random data
  • New password
  • New password length

Of these the original client challenge, the random data, and the new password are easily set to all zeros.  In theory, the server should verify the current time and disallow a zero-length password.  However, this is not the case, making it possible to set the domain controller’s password to empty.

While changing this password does not enable the attacker to log into the machine, it does enable them to access the Domain Replication Service Protocol.  This enables them to extract the password hashes of domain administrator accounts, enabling them to generate Kerberos golden tickets.  Additionally, these hashes could be used in a pass-the-hash attack to log into the Domain Controller and as Domain Administrator and reset the password manually.  This provides the attacker with full access and control over the network.

However, this is not even the only way to exploit the Netlogon vulnerability.  A writeup by Dirk-jan Mollema describes another method that takes advantage of the NTLM protocol to gain Domain Administrator access without changing a password (which can crash services).  However, this version of the exploit requires two vulnerable domain controllers, an available domain user account, and a print spooler service running on a DC and accessible from the network (default domain controller configuration).

Zerologon Exploitation in the Wild

The patch for Zerologon was released in August 2020, and the details of the vulnerability weren’t publicly announced until September 2020.  In theory, this provided organizations with ample opportunity to apply the patch and eliminate the vulnerability.

In practice, many organizations have not applied the patch, leaving them vulnerable to exploitation.  Microsoft publicly announced that they have detected active exploitation of the vulnerability, and the Department of Homeland Security (DHS) issued a directive on September 18th requiring federal agencies to patch the issue by September 21st (i.e. the following Monday).

This is due to the fact that the vulnerability was expected to be actively exploited by cybercriminals.  This belief is backed up by a report by Tenable that multiple different exploit executables were uploaded to Virustotal.

Protecting Against Zerologon

The Zerologon vulnerability is patched in the August 2020 set of Windows updates, and is blocked by some endpoint security solutions.  Microsoft recommends taking the following steps to fix the issue:

  1. Update Domain Controllers with the patch released in August 2020.
  2. Monitor patched Domain Controller logs for event IDs 5829, 5828, and 5829.  These events indicate a client that is using a vulnerable netlogon secure channel connection and require either a Windows or manufacturer update.
  3. Enable Domain Controller Enforcement Mode for additional visibility and protection.

After patching known domain controllers and other known affected systems, it might be wise to undergo a penetration test to discover other potentially vulnerable devices.  The vulnerability affects most versions of Windows Server, which can be deployed in a number of different environments and contexts.