The security of U.S. election systems was a major water-cooler topic this summer. There was plenty of media buzz about the potential of Russians hackers infiltrating our voter databases and trying to manipulate the upcoming presidential election. Most recently, the Arizona Secretary of State's office closed down the state's voter registration system after a hacker compromised valid credentials and used them to access the system. Shortly after that incident, someone exploited the IVRS (Illinois Voter Registration System).
A message posted to Facebook, purportedly written by Kyle Thomas, director of the election board’s voting and registration systems division, stated that the IVRS compromise was a direct result of a SQL injection attack and that the records for up to 200,000 voters were accessed.
"The offenders were able to inject SQL database queries into the IVRS database in order to access information. This was a highly sophisticated attack most likely from a foreign (international) entity," the message posted to Facebook explained.
And now we have a leaked FBI memo that, although it doesn’t name Illinois and Arizona, announces that “foreign actors” used common scanning tools to find and exploit vulnerabilities in election systems. The memo also listed internet protocol addresses associated with the hacks.
The leaked FBI memo recommends that states “contact their Board of Elections and determine if any similar activity to their logs, both inbound and outbound, has been detected.”
Stop worrying about attribution
Most of the headlines about these stories were quick to blame the Russians by name, but few mentioned the “SQL injection” vulnerability. And that’s a problem. Training the spotlight on the “foreign actors” is misguided and, frankly, unproductive. There is a lot of talk about the IP addresses related to the hacks pointing to certain foreign entities. But there is no solid evidence to make this link—attribution is hard and an IP address is not enough to go on.
The story here should be that there was a simple to find and fix vulnerability in a state government election website. Rather than figuring out who’s accountable for the breach, we should be worrying about who is accountable for putting public data at risk. Ultimately, it doesn’t matter who hacked the system because that doesn’t make the vulnerabilities any harder to exploit or the system any safer. The headlines should question why taxpayer money went into building a vulnerable system that shouldn’t have been approved for release in the first place.
Start worrying about securing code
Contrary to many of the sensational headlines about the election system breaches, these were not complicated or “sophisticated” attacks. The attackers used off-the-shelf and free, open-source tools, which require a very low skill level to use. Bottom line: These types of attacks are not hard to perpetrate. But they are also easy to defend against, yet we seem to be missing this point. The FBI Flash report did not recommend states test their election systems for SQL injection and work to repair them. It did recommend installing IOCs (indicators of compromise).
This type of advice leads to a mindset of “learned helplessness,” where IT professionals sit and wait for their systems to be hacked. But we should not be sitting ducks. We know how to fix simple vulnerabilities like SQL injection. We know how to find it in our code and vendor-purchased code. We know that proactive measures like application security make computers systems harder to hack.
The advice the FBI should be giving is: “Your election systems will continue to be attacked until you fix your SQL injection. Hold your developers and suppliers accountable and have them demonstrate that they are testing and removing SQL injection-type vulnerabilities before you accept the code.” The idea that we are helpless to fix vulnerabilities and must continually update our detectors with the latest IOCs is a decade-old way to think about web vulnerabilities.
We should start talking less about who the hackers are, and more about who should be held accountable for providing secure software.