[BreachExchange] Election system hacks: We're focused on the wrong things

Inga Goddijn inga at riskbasedsecurity.com
Wed Sep 21 17:37:29 EDT 2016


http://www.infoworld.com/article/3120325/application-development/election-system-hacks-were-focused-on-the-wrong-things.html

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
<https://www.facebook.com/permalink.php?story_fbid=1144387868951159&id=215366205186668>,
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20160921/661efe47/attachment.html>


More information about the BreachExchange mailing list