Can malware and hackers really cause giant physical disasters?

Right back to the 1980s, when computer viruses first appeared in any number, people have been asking, “Can malware and hackers cause giant physical disasters?”

As if draining your bank account, “borrowing” your network connection to send 5,500,000 spams a week, or blowing away all your data and offering to sell it back for $300 were not enough…

…there has long been an understandable fascination with whether computer malfeasance alone – let’s call it hacking, in the pejorative sense of the word – can, in three not entirely precise words, “blow stuff up.”

There’s a lot of well-meaning concern at the moment that such an outcome might very well be possible, at least figuratively, thanks to buzzwords such as SCADA and IoT.

SCADA is a handy acronym, because it’s short for the rather clumsy-sounding supervisory control and data acquisition.

→ Treated as a word in its own right, SCADA is pronounced skay’der to rhyme with raider, or, less frequently, scad’der to rhyme with ladder. Don’t say scar’der to rhyme with larder. Lengthening the first -A- in SCADA doesn’t make sense, considering that it stands for “and”.

SCADA refers to the interfaces, sometimes proprietary, sometimes open, that allow industrial equipment to be connected to, programmed by, and controlled from regular computers, like PCs or Macs.

Of course, that raises the questions, “Could that industrial equipment end up on the public internet? How safe would that be?”

The answers, loosely speaking, are, “Yes,” and, “Are you sitting comfortably?”

And IoT is short of Internet of Things, which is another way of saying SCADA for sub-industrial devices, such as home thermostats, remote-control garage doors and even individual light bulbs around your house.

Of course, that raises the questions, “Could those light bulbs end up on the public internet? How safe would that be?”

The answers, loosely speaking, are, “Yes,” and, “Are you sitting comfortably?”

In short, you might well assume that hacker-driven disasters, featuring heavy-duty equipment such as power stations, water purification plants and aluminium smelters, would be reported all the time.

Malware-initiated meltdown

Fortunately, there aren’t actually many known examples of malware-initiated meltdown.

In fact, there’s Stuxnet, and…so far, that’s about it.

Stuxnet, in case you’ve forgotten, is a virus that is said to have been designed to infiltrate Iran’s uranium enrichment facilities, using .EXE files on USB keys to jump between electrically-disjoint networks, and then to reprogram the centrifuges to wobble themselves into dysfunction.

It’s not literally “blowing stuff up,” nor yet “melting something down,” but you could be forgiven for referring to it metaphorically in either of those ways.

We’ll probably never know for sure whether Stuxnet actually reached its intended targets and genuinely worked (indeed, it would be a handy scapegoat if Iran’s centrifuges broke for other more pedestrian reasons, such as overuse), but we’ll pretend that it did, and chalk it up as our first example.

But in 2014, according to the Federal Office for Information Security in Germany, which just published its annual IT Security Report, we had the dubious honour of a second “meltdown” example for the history books.

→ The Federal Office for Information Security is officially known in German as the BSI, short for Bundesamt für Sicherheit in der Informationstechnik.

Actually, this one was more of a smeltdown, following a targeted attack on a German steelworks.

The report suggests that the crooks got in by the tried-and-trusted mechanism of spear-phishing and social engineering.

Thereafter, they worked their way from the business network into the production network (what is known in the penetration testing industry by the gymnastic-sounding jargon pivoting and moving laterally, as one might in a tricky rock climb), and messed up the control of various equipment.

In particular, the failures meant that:

[E]in Hochofen nicht geregelt heruntergefahren werden konnte und sich in einem undefinierten Zustand befand. Die Folge waren massive Beschädigungen der Anlage.

A blast furnace could not be correctly shut down and ended up in an undefined state. The result was massive damage to the system.

According to the BSI:

Das Know-how der Angreifer war nicht nur im Bereich der klassischen IT-Sicherheit sehr ausgeprägt, sondern erstreckte sich auch auf detailliertes Fachwissen zu den eingesetztenIndustriesteuerungen und Produktionsprozessen.

The attackers not only had highly developed skills in conventional IT security, but also possessed detailed practical knowledge about industrial control and production processes.

The bottom line

We’ll ignore the intricacies of, and advice for, securing your SCADA systems until another time, and focus here on the spear-phishing angle.

As we explained in Sophos Security Chet Chat 178, spear-phishing is surprisingly similar to regular phishing, where bogus emails urge or pressurise you to visit a website or open an attachment that you would usually ignore.

In a spear-phishing attack, the emails aren’t entirely untargeted, but instead focus on facts that are apparently relevant and interesting to you.

Those facts could be deduced from your hobbies, your job description, your Facebook profile, or many other sources, both legitimate (e.g. social networks) or underground (e.g. stolen copies of your resume).

As we advised in our recent article about Christmas-time iTunes phishing, try these tips:

• Think before you click. Dodgy emails often sound believable at first, either because the crooks know enough about you to refer to something you are interested in, or because they got lucky and mentioned something you are familiar with.
• Use two-factor authentication (2FA) if you can. 2FA generally relies on one-time login codes, so the crooks can’t simply phish your password and use it over and over.

Image of fireball courtesy of Shutterstock.