in the Internet of Things
A bit of background and a short introduction.
November 2016, Tobias Oberstein & Alexander Gödde,
Why is this important?
Your devices don't just know what you did last summer...
... but everything that you do!
It's one thing when your PC crashes...
... but another thing when your brakes fail while you're on the Autobahn!
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)
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 (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
- 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."
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
- 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 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
In practice, there is a double NAT'ted network often
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:
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?
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?
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
- 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!
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!