Security
in the Internet of Things

A quick overview of the problem & some aspects of solving it.

November 2016, Tobias Oberstein & Alexander Gödde, Crossbar.io

Part I: Background

Why is this important?

  1. Privacy
    • Your devices don't just know what you did last summer...
    • ... but everything that you do!
  2. Physical Safety
    • It's one thing when your PC crashes...
    • ... but another thing when your brakes fail while you're on the Autobahn!
  3. Keeping the Internet working
    • It's one thing when your camera gets hacked...
    • ... but another thing when nobody can access the Net anymore because it's part of a botnet!

For example (1)

Hackers were able to

  • control the entertainment system
  • track the position of the car remotely
  • read the CAN bus
  • control the engine, transmission, braking system

via the wireless network and without pyhsical access to the car!

... to do this they needed to

  • hack the Sprint cell network
  • scan the network for cars
  • brute-force the password for access to the entertainment system
  • reprogram an embedded controller to get write access to the bus.

It took them years of tinkering - but then there are a lot of people out there with time on their hands!

FiatCrysler had to recall 1.4 million cars.

For example (2)

Hackers were able to

  • hijack several 100k IoT devices (e.g. CCTV cameras)
  • use them to procude > 1 TBit/s traffic directed at Dyn (DNS provider)
  • comparison - DE-CIX ~5.5 TBit/s (world's biggest internet exchange)

This meant that Web sites using Dyn for DNS were unreachable for hours.

Services affected include Twitter, GitHub, PayPal, Amazon, Reddit, Netflix and Spotify.

... to do this they needed to

  • download a toolkit ("Mirai")
  • set up the toolkit
  • run the toolkit
  • choose a target

The toolkit does port scans and then tries to log in using 61 user/password combinations.

Examples: 'root'/'root', 'admin'/'123456' (seriously!)

IoT Device Security is Bad

Some numbers from two separate studies: Of the IoT devices tested

  • 50% didn't use transport encryption
  • 60% didn' have secure update mechanisms
  • 60% had cross-site scripting vulnerabilities in their Web interfaces
  • 40% had no protection against replay attacks

What's the problem?

  • Security for networked devices is a hard problem.
  • Time-to-market, features and price are immediate positives, while security problems are a distant negative.
  • Companies from other industries are now doing networked software, and they use their engineering mindset.

How big is the problem?

  • attack on Brian Krebs' Web site: 145,000 devices, 620 GBit/s
  • ~5 million IoT devices going oline per day (Gartner, for 2017, but still)
  • a lot of these devices can't be updated
  • the vast majority is never going to be updated

"The Internet of Unpatchable Devices" (Akamai)

Part II: Technology & Solutions

  • Attackers
  • A simple IoT application
  • Network Attack Surface Minimization

Attackers

  1. Who are the attackers?
  2. What do attackers want?
  3. What abilities do attackers have?

1. Who are the attackers?

  • Security researchers & Hackers
  • Script kiddies
  • Criminals
  • Competitors
  • States & agencies
  • Employees & Insiders
  • One more: vendors!

2. What do attackers want?

  • Control systems
  • Disrupt systems
  • Steal data
  • Manipulate data
  • Ultimately: $$$ or plain fun

3. What abilities might attackers have?

  • Wiretap your network
  • Selectively drop traffic from your network
  • Selectively replay traffic on your network
  • Inject arbitrary traffic into your network
  • Flood your network and systems with noise
  • Impersonate devices & systems
  • Insert an USB stick into a system/device
  • Physically destroy a device
  • Talk an employee into disclosing his/her password
  • ... (lots more) ...

They always have access to the internet.

A simple IoT app

So what's the big deal?

We need to talk to the device.

Alright, I can do that!

"Solution"

Let's just use HTTP, m'kay?

We are doing a HTTP/POST request to

http://device73012.example.com/led/1

with a POST body either "ON" or "OFF"

The HTTP server listens on port 80.

We are done!

Browsers, Web servers, languages, .. all talk HTTP.

Everyone knows HTTP. It's all there.

And to make it secure, we'll just add HTTPS (TLS).

That was easy. Let's go for a drink!

Wait a minute ..

It's not secure

Let's summarize

  • the software on the device has vulnerabilities
  • the open port allows probing of the device
  • the device has limited computing capabilities
  • there may not be any updates for the device
  • the device will most likely not be updated

Do you want a listening port
on your device in the first place?

How do we get rid of the open port?

HTTP Polling

Here is a HTTP based design with strictly outbound connections using "polling":

We are done!

The network issue is fixed. And it's secure.

Let's have that drink now!

Weell. Sorry to disturb, but there is a price.

Issues with HTTP Polling

Polling works "Ok", but comes at a price:

  • Traffic volume
  • Message latency

Traffic volume and message latency are two major performance metrics in IoT applications.

HTTP Polling Alternatives

So what's better than HTTP Polling?

  • HTTP Long-polling
  • WebSocket
  • raw TCP?

A message router architecture

Here is our approach for building
scalable and secure IoT applications:

  • clients establish connections to the router
  • no open ports on devices
  • wide range of authentication mechanisms

... but now we have open ports on the router!

Some truths

  • you need open ports somewhere
  • some part of your application will be vulnerable
  • security is about choosing your battles wisely

Choose wisely where you are vulnerable

  • single router, large numbers of devices
  • single point to protect
  • single point to update
  • router runs on more potent, more accessible hardware

Principles of Network Attack Surface Minimization

Rule 1: There must not be any listening port on a device (all inbound connections must be blocked).

Rule 2: All application code must be separated from network server code.

Is this a silver bullet? Will it bring peace on earth?
Sorry, nope. But it's a good approach to start with.

Thanks for your attention!

Questions?