When a Russian-speaking hacker cracks a US Election website…

Lots of people seem to be seriously worried about the question, “Did Russia hack the US election?”

To many observers outside the US, the US electoral system, with its executive presidency and its electoral college, is confusing on its own.

On top of that, the electoral process adds yet more confusion, seeming both haphazard and gratuitously varied in equal measure, particularly to people who have never lived in a federation where the individual states or provinces are almost like countries in their own right.

In the US, even in a federal election, electors might vote by writing their choices onto paper in one US state, by touching a screen in a second, or by punching cards in a third.

Ironically, this sort of technological diversity, for all that it seems disorganised and inconsistent, almost certainly made the chance of a direct “election hack” (whatever that means) less likely, or at least significantly harder to pull off in any broad way.

Furthermore, there isn’t just state-by-state variety in voting methods, but often a huge array of additional voting topics tacked onto the major question of the federal President, with different parts of the US using the opportunity of the presidential election to ask a range of other ballot questions at the same time.

For example, five states added a “Would you like to legalise cannabis?” question to their 2016 presidential election voting sheets, balloting it variously as Proposition 64, Question 4, Question 2, Question 1 and Proposition 205.

(In case you are wondering, California, Massachussets, Maine and Nevada said yes; Arizona, where it was Proposition 205, said no.)

Of course, you can influence an election without directly hacking it, which is one of the reasons we’ve been reading so much about fake news stories lately.

Two years ago, the main “fake news” problem we had to worry about was a bubbling cauldron of arrant online nonsense about a paedophile cat (you can’t make this stuff up) called Talking Angela.

Now, however, it seems that there is much more at stake, even the possible outcome of an election, where cleverly timed fake stories might apparently, even at the very last minute, sway our own carefully formed and closely held opinions, such as whom to put in the Oval Office.

Don’t be alarmed

So any data breach story that mentions the phrases “Russian-speaking hacker” and “US Election” sounds like a huge cause for alarm.

Fortunately, however, this is a data breach that couldn’t have affected the election, for two important reasons: it happened after the election was decided, and it happened to the US Election Assistance Commission (EAC), which doesn’t run, administer or count the votes in any elections.

Nevertheless, as its name suggests, the EAC has an important role in getting the US to the polls, including testing and certification for voting machines, of which there are many.

That’s why the EAC’s post-election breach was very embarrassing, apparently involving what’s called a SQL injection vulnerability.

That means the hacker was able to embed a database command inside what was supposed to be just data passed to a database query, and to trick the database server into running that data as a mini-program.

Understanding SQL injection

SQL injection is a type of attack that was immortalised in an XKCD comic strip about a child known as Little Bobby Tables:

As you can see in the cartoon, Bobby’s mother didn’t just call him Robert, as most Bobs start out in life, but instead gave him the prolix name Robert'); DROP TABLE Students;--.

If his hackername is ever allowed directly into a SQL database search query, and the query program doesn’t detect and block those semi-colon characters, then what was supposed to be this…

…will instead come out like this:

(In both these commands, the data inserted from the query request itself is denoted in bold.)

The reason for the extra quote mark, the semicolons and the double-dash at the end are now clear.

The semicolons allow multiple SQL commands to be put one one line, something that programmers often like to do for neatness, or to make their code look more cleverly compact that it really is.

So the Little Bobby Tables query actually gets executed like this:

The first command is what you’d expect; the second injected command deletes the whole database (but could also steal data, implant malware, change records and more); and the third command turns into a harmless SQL comment.

The reason for including the -- characters in Little Bobby’s full name is that Robert’s hacker mom can’t stop the original SQL query builder adding the closing '); characters, because they’re needed in regular queries. If they were inserted directly after the second semicolon, they’d appear on a line of their own. That would produce an error, which would either stop the query running altogether, or produce a telltale log message. Arranging for the unwanted trailing characters to be preceded by a -- comment marker means that the offending characters are simply ignored.

What do do?

Don’t pass user-supplied data directly into a server back end system for execution.

Perform what’s called input sanitising first.

For example, you can permit remote users insert text like ROBERT into an HTML page – for example, in the search field that you echo back in the heading of a search result.

But you mustn’t allow remote users to insert text like ROBERT<SCRIPT SRC=... or else the HTML will sneakily include a SCRIPT tag, started by the less than sign, which means that a crook can include a JavaScript program.

Likewise, you can’t allow semicolons into SQL queries, or into Bash scripts (as some hapless Netgear routers were doing until recently), or else remote users may be able to insert multiple command statements, just as in the XKCD cartoon above.

You can’t allow > or >> into scripted queries either, because shell scripts use the greater than signs to send (or to append) output to a named file instead of the screen, which could allow a crook to tamper with existing files remotely.

As you can imagine, these examples only scratch the surface.

There are lots more things to do before you let user-specified data near a back end system where it could cause trouble.

If you aren’t sure what you need to do, we suggest starting with the OWASP Cheat Sheets.