It’s good to see that Americans are starting to take voting systems security seriously. Secure voting is essential to democracy, but as with most other systems, no one thinks about it until there’s been a hack.
Hopefully the upcoming vote recount will tell us if our voting systems have been hacked, if in fact there’s any evidence left behind. Chances are any actual hacking evidence is gone, especially since it’s unlikely there are any forensic recordings to rely upon.
But if hacks of voting systems did take place, what are the likely methods the bad actors used? What can we learn from the multitude of hacks we’ve seen over the years against retailers, banks, payment processors, and government agencies?
Hackers begin their attacks with reconnaissance. This typically happens months before the actual attack, where they scan the systems they are targeting and learn the technical and business rules and logic they must circumvent in order to perpetrate their crimes.
For example, on the technical side, they learn what authentication measures are used to access systems and what record layouts are used to transmit messages. They also learn what the transaction verification and audit trails look like. On the business side, they learn the logic used by oversight systems that single out ‘exception transactions’ and detect fraud.
We saw this criminal reconnaissance work effectively in the SWIFT attacks. The criminals learned how to circumvent the strong SWIFT authentication processes. They deciphered the SWIFT payment messaging protocol so that they could change the payee where stolen funds were directed, and they even learned how to overwrite the paper trail that was produced to audit and verify SWIFT transactions at the originating banks.
The SWIFT fraudsters also studied the business logic so that their transactions would not be detected. But they eventually messed up because they didn’t foresee the anti-money laundering (AML) rules that the NY Fed would apply to the Bank of Bangladesh transactions. The NY Fed AML oversight function eventually detected and halted the Bangladesh heist when only some $80 million dollars was already stolen (rather than the intended $1 billion plus).
What this means to the U.S. election:
If there were hackers, they would have engaged in such reconnaissance. They would have learned which important swing states to target, how to infiltrate them, and how to circumvent any business and technical controls therein. In fact, the FBI issued alerts last August that foreign hackers were scanning and infiltrating state election servers. They reported that voter registration databases were compromised but it’s entirely plausible – in fact I think highly probable – that the hackers also left malware behind on those servers. It’s my understanding that DHS did not do anything about it afterwards other than offer the states technical assistance since those servers are not under ‘federal jurisdiction.’ I also understand no-one took them up on their offer.
Hackers launch their attack through the point of least resistance. In the case of the Target breach, that was an HVAC contractor whose account was hijacked by remote criminals and used to get inside Target’s credit card network segment. At banks, that point is often a corporate customer who is socially engineered to give their ‘strong’ authentication credentials away to the fraudster so that their account can be hijacked and money can be siphoned out.
It’s also important to note that hackers typically plant malware on a victim’s desktop that sits and waits until it’s time to act. At Target, that time to act was when the HVAC contractor logged into the Target supplier system. At Banks, the time to act is when a corporate customer logs into their bank.
What this means to the U.S. election:
If there were hackers, they likely got in by spearfishing employees or contractors that worked in state or local government agencies. It also means that the malware would have been waiting for Election Day to activate and there wouldn’t have been any noticeable suspect cyberattack activity external to those servers. So it doesn’t mean anything when the federal government says they didn’t see any attack activity on Election Day. In fact it sounds somewhat disingenuous for them to make this hollow statement. Further, the federal government has no jurisdiction over state or local election servers so they couldn’t have been monitoring those machines unless they were specifically requested to.
Hackers go to the point of least resistance. When widespread attacks against the U.S. credit card systems began around 2006, attackers went into centralized databases at payment processers or retailers (e.g. Card Systems International and later on TJX and Co.) and stole credit card data stored therein. After PCI standards were widely enforced, hackers had a harder time finding unencrypted centrally stored data so they started going after centralized pockets of data in transit, for example at Heartland Payment Systems whose hack was announced the day Obama was first inaugurated.
Once the central processors further tightened their security controls, the hackers moved on to decentralized retailer Point-of-Sale (POS) systems such as those at Target, Home Depot and countless others. The fraudsters migrated their attacks to distributed POS systems where they siphoned off credit card data in memory from very specific memory addresses they learned during their reconnaissance phase. So even as security controls tightened at retailers, it would now be very difficult to find traces of their memory resident ‘fileless’ attacks.
It’s also worth noting that hackers often break into retail POS systems by compromising the POS management systems that have administrative rights over distributed POS applications.
What this means to the U.S. election
If hackers attacked our election servers, they probably would have gone to the point of least resistance which are likely the centralized state reporting systems, and not the local voting systems. It would be relatively easy for them to add, change or delete votes in those central systems.
But if the hackers wanted the original votes (in paper or electronic formats, depending on the precinct) to match the reported votes in case of an audit, they would have had to figure out how to alter the original votes in dozens of precincts.
This would be extremely difficult, although not entirely impossible assuming bad actors are able to recruit insiders to help them alter paper evidence, and assuming they gained administrative access to voting management systems so that they could alter electronic votes and audit trails. More remotely, determined hackers could have or can in the future compromise the application source code with back doors. See Voting machine application security for analysis of voting machine application security. (Recent intelligence reports indicate that unfriendly nation states continue to target various U.S. organizations by placing duplicitous IT developers on those firms’ payroll, so that they can plant back door traps in their software).
Hackers have for years been covering their tracks by deleting evidence and by overwriting paper receipts that are printed from computer files. For example, during the SWIFT attacks, hackers altered the contents of the expected PDF audit and receipt files that legitimate users rely on to verify their transactions went as planned. The SWIFT hackers wrote to the PDF files the values (e.g. transferred amount and recipient) the users THOUGHT they were transacting, and NOT the values the hackers had inserted into the transaction stream to steal their money. For at least six years, financial fraudsters using Zeus and other banking malware have overwritten screen displays that corporate banking users see after they execute a money transfer to display the amount and recipient the corporate user HAD INPUT instead of the unauthorized amount and recipient the hacker ACTUALLY transferred the money to.
In government hacks, such as the infamous Snowden hacks, advanced threat actors know exactly how to hide their tracks in audit trails that systems they hack use to monitor security events. The hackers either keep records of their activities from being inserted into audit trails in the first place or they alter the audit trail records that are produced to hide their tracks.
What this means for the U.S. election:
Assuming there were nation state hackers, it would have been very easy for them to hide their electronic tracks using methods described above. I strongly doubt that state or local government systems have advanced recording features in place, such as those provided by EDR systems that trace every process on a host and endpoint. It would have also been relatively easy for them to overwrite paper trails originating from electronic data that they manipulated. However, it would be virtually impossible for the hackers to alter paper votes in distributed precincts without the help of insiders.
As a longtime observer of many hacks and data breaches, I can’t help but wonder if our political voting systems have been hacked. From working with state and local governments, I know very well how budget constrained they are. They simply don’t have the resources to take on nation-state hacking. Even defense contractors, the NSA and large well-endowed and smart corporations struggle with this. At a minimum this election should teach us that local voting systems need help with security and they should be considered national critical infrastructure so that federal funding and assistance can apply.
But we shouldn’t hold our breath for that. At a bare minimum, election systems should put in place secured recordings of all activities that take place on their hosts so that at the least, potential hacks can be properly investigated. EDR systems are useful for this. They function as the ‘black box’ in the airplane that crashed.
Too late to stop the crash but at least we can determine what happened after the fact. In the case of the U.S. elections, I would bet that we don’t even have those black boxes.
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.