in the Internet of Things

A bit of background and a short introduction.

November 2016, Tobias Oberstein & Alexander Gödde,

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 physical 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 produce > 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!)

Some more IoT Hacks

  • A Samsung smart fridge could be tricked into giving up a user's Google account credentials via wi-fi.
  • A Samsung smart TV allowed remote access to its camera.
  • A blast furnace couldn't be shut down in a German Steel Mill, damaging the furnace itself.
  • A system of drug infusion pump was take off the market because of a remote control vulnerability.

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 hard.
  • 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 online 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: Introduction

Security in IoT

  • Attackers, Threat Models and Attack Surface
  • Network Security for a simple IoT application
  • Network Attack Surface Minimization

Attack and Attack Surface

  • Attack (def.):
    "Any kind of malicious activity that attempts to collect, disrupt, deny, degrade, or destroy information system resources or the information itself."
  • Attack surface (def.):
    "Sum of all different entry points (= attack vectors) in a system or application that can be used to perform an attack."

Threat Model

  • Threat Model (def.):
    abstraction of a particular set of security threats
  • A threat model is a tool of thought (and communication) for developers, administrators and security researchers

Threat Model

  • Example: "A chosen-plaintext attack is an attack model for cryptoanalysis which presumes that the attacker can obtain the ciphertexts for arbitrary plaintexts."
  • Different alternative software designs, implementations and algorithms can be compared under a given threat model
  • Threat models can be compared to each other: "A chosen-plaintext attack is more powerful than a known-plaintext attack, but less powerful than a chosen-ciphertext attack."

Useful Questions

Abstract definitions are nice, but here are some practical questions you might ask to better understand the threats you face:

  • Who are the attackers?
  • What do attackers want?
  • What abilities do attackers have?

Who are the attackers?

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

What do attackers want?

  • Control your systems
  • Disturb the function
  • They want your data
  • Manipulate your data
  • Ultimately: $$$ or plain fun

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 password
  • ... (lots more) ...

A network threat model

We'll be looking at an IoT app under this threat model:
the (remote) attacker has TCP/IP level network access and is able to ..

  • wiretap any traffic
  • selectively drop traffic
  • selectively replay traffic
  • inject arbitrary traffic

A simple IoT app

We have a device with a LED and want to turn on/off the LED from a browser running anywhere.

This app will rock. Totally!

"We have a device with a LED and want to turn on/off the LED from a browser running anywhere."

Btw: this is what people call "Command & Control"

So what's the big deal?

We need to talk to the device

More so: talk from the browser to the device

Alright, I can do that!


Let's just use HTTP, m'kay?

We are doing a HTTP/POST request to

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

On the device we have a HTTP server listening on port 80.

The Web server runs a small script that controls the LED.

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 doesn't work

It's not secure

It doesn't scale

Network Issues

In practice, there is a double NAT'ted network often

Network Issues

The problem: most often, a device lacks a public routable IP (NAT) and lacks a public hostname also

Here are (non-working) approaches to fix:

  • Port forwarding
  • VPN
  • IPv6

Network Issues

Alright, so how do I fix the network issue?

By asking the right question first;)

Because the bigger issue is: open ports are a security issue anyway!

We won't touch even more security issues like: how are you going to distribute your TLS certificates for all the device Web servers? etc etc

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

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

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!