[BreachExchange] RoT: Ransomware of Things

[Audrey McNeil]

http://www.welivesecurity.com/2017/01/25/rot-ransomware-things/

One of the trends that I found most worrying in 2016 was the willingness of
some individuals to participate in the following three activities: holding
computer systems and data files hostage (ransomware); denying access to
data and systems (Distributed Denial of Service or DDoS); and infecting
some of the devices that make up the Internet of Things (IoT).

Sadly, I think these trends will continue to evolve in 2017 and there is
potential for cross-pollination as they do so. For example, using infected
IoT devices to extort commercial websites by threatening a DDoS attack, or
locking IoT devices in order to charge a ransom – something I like to call
“jackware”.

Past and future threats

Abusing information systems to extort money is almost as old as computing
itself. Back in 1985, an IT employee at a US insurance company programmed a
logic bomb to erase vital records if he was ever fired. Two years later he
was – and, accordingly, the bomb erased the records, leading to the first
conviction for this type of computer crime.


So how might these elements evolve or merge in 2017? Some people have been
referring to 2016 as “The Year of Ransomware” and I’m concerned 2017 could
be dubbed “The Year of Jackware”.Malware that used encryption to hold files
for ransom was identified in 1989, as David Harley has recounted. In 2011,
my colleague Cameron Camp described locking computers for a ransom as
“stooping to new lows”.

Think of jackware as malicious software that seeks to take control of a
device, the primary purpose of which is neither data processing nor digital
communications. A good example is a “connected car”, as many of today’s
latest models are described. These cars perform a large amount of data
processing and communicating, but their primary purpose is to get you from
A to B.

So think of jackware as a specialized form of ransomware. With regular
ransomware, such as Locky and CryptoLocker, the malicious code encrypts
documents on your computer and demands a ransom to unlock them. The goal of
jackware is to lock up a car or other device until you pay up.

Picture this: on one particularly cold and frosty morning I use the car app
on my phone to remote start my car from the comfort of the kitchen, but the
car does not start. Instead I get a text on my phone telling me I need to
hand over X amount of digital currency to re-enable my vehicle. This is
what jackware could look like from a victim’s point of view. Fortunately,
and I stress this: jackware is, as far as I know, still theoretical. It is
not yet “in the wild”.

It’s not easy to prevent jackware being developed and deployed; especially
considering previous examples. We have already seen that a car company can
ship more than a million vehicles containing vulnerabilities that could
have been abused for jackware: take the Fiat Chrysler Jeep problem that was
all over the news in 2015.

An equally serious case was the Financial Conduct Authority’s (FCA)
apparent lack of planning for vulnerability patching in the vehicle design
process. It is one thing to ship a digital product in which ‘holes’ are
later discovered – in fact, this is pretty much inevitable – but it is a
different and more dangerous thing to ship digital products without a quick
and secure means of patching those holes.


We also saw this infrastructure issue in 2016 when some Fitbit accounts had
problems (to be clear, the Fitbit devices themselves were not hacked, and
Fitbit seems to take privacy seriously). Also this year, bugs were
discovered in the online web app for BMW ConnectedDrive, which connects
BMWs to the IoT. You can use the BMW ConnectedDrive to regulate your home’s
heating, lights, and alarm system from inside your vehicle.While most “car
hacking” research and discussion centers on technical issues within the
vehicle, it is important to realize that a lot of IoT technology relies on
a support system that extends well beyond the device itself. We saw this in
2015 with VTech, a player in the Internet of Children’s Things (IoCT)
space. Weak security on the company’s website exposed personal data about
children, reminding everyone just how many attack surfaces the IoT creates.

The possibility that the features and settings of an in-vehicle system
could be remotely administered through a portal that could be hacked is
unsettling to say the least. And reports of vehicular cyber-insecurity keep
coming, like this Wi-Fi enabled Mitsubishi, and hacked radios used to steal
BMWs, Audis, and Toyotas.


Stopping the RoTWhile I originally thought of jackware as an evolution of
malicious code targeting vehicles, it was soon clear that this trend could
manifest itself more broadly – think “the Ransomware of Things (RoT)”. A
chilling story from a city in Finland indicates one direction that this
might take (DDoS attack halts heating in Finland in winter). While there
was no indication of ransom demands in the reports, it does not take much
imagination to see this as the next step. Want us to stop DDoSing the
heating system? Pay up!


To stop the IoT becoming home to the RoT, a number of things need to
happen; in two different spheres of human activity. First is the technical
sphere, where the challenge of implementing security on a vehicular
platform is considerable. Traditional security techniques like filtering,
encrypting and authenticating can consume costly processing power and
bandwidth, adding overhead to systems, some of which need to operate with
very low latency. Security techniques like air-gapping and redundancy could
potentially contribute significantly to increasing costs of vehicles. And
we know that controlling costs has always been critical to car
manufacturers, down to the last dollar.

The second sphere in which action against the RoT should be taken is policy
and politics. There has been a collective international failure to prevent
a thriving criminal infrastructure evolving in cyberspace; one that now
threatens every innovation in digital technology you can think of, from
self-driving cars to drones; from big data to telemedicine. For example, as
alluded to in Challenges and Implications of Cybersecurity Legislation,
concerned politicians failed to pass legislation in 2016 that would help
secure the smart grid, despite bipartisan support.

First, a variety of government agencies are stepping up their efforts to
make the IoT more secure. In 2016 we saw the publication of the Strategic
Principles for Securing the Internet of Things from the US Department of
Homeland Security, and the NIST Special Publication.To be clear, terms like
RoT and jackware are not intended to cause alarm. They symbolize things
that could come to pass if we do not do enough in 2017 to prevent them from
becoming a reality. So let me end with some positive developments.

The full title of the latter is Systems Security Engineering Considerations
for a Multidisciplinary Approach in the Engineering of Trustworthy Secure
Systems. NIST is the National Institute of Standards and Technology, part
of the US Department of Commerce, and over the years the agency has exerted
a positive influence on many aspects of cybersecurity. Hopefully, these
efforts – and the many others around the world – will help us make progress
in 2017, working towards the goal of securing our digital lives against
those who choose to abuse technology to extort us.

Finally, evidence that we might be making some progress – at least in terms
of public awareness of the IoT’s potential to bring problems as well as
perks and productivity gains – comes from a different kind of publication:
the results of an ESET consumer survey. Reported under the title of “Our
Increasingly Connected Digital Lives” the survey revealed that more than
40% of American adults were not confident that IoT devices are safe and
secure. Furthermore, more than half of respondents indicated that privacy
and security concerns had discouraged them from purchasing an IoT device.

Could the combination of consumer sentiment and government guidance lead
companies to make the IoT more resistant to abuse? We may find out in 2017.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20170125/4cd28553/attachment.html>