1. Security and Privacy in the Internet of Things
Elisa Bertino
CS Department and Cyber2SLab

2. The IoT – Wikipedia
The Internet of Things (IoT) is the network of physical objects or "things" embedding electronics, software, and network connectivity, which enables these objects to collect and exchange data.
The IoT allows objects to be sensed and controlled remotely across existing network infrastructure, creating opportunities for more direct integration between the physical world and computer-based systems.
When IoT is augmented with sensors and actuators, the technology becomes an instance of the more general class of cyber-physical systems, which also encompasses technologies such as smart grids, smart homes, intelligent transportation and smart cities.
Diagram from K. Angrisci “Turning IoT into Internet of
Vulnerabilities: IoT Botnets”
Things can refer to a wide variety of devices such as heart monitoring implants, biochip transponders on farm animals, automobiles with built-in sensors, or field operation devices that assist fire-fighters in search and rescue.
Mention:
Privacy
Concrete cyber threats
Influencing human behavior

3. Industrial IoT (IIoT)
Diagrams and examples from Accenture “Driving the Unconventional Growth through the Industrial Internet of Things”, 2015,
downloaded from

4. Industrial IoT (IIoT)
Diagram from BSQUARE. Annual IIOT Maturity Survey. 2017

5. IoT dramatically expands the attack surface
IoT - Risks
IoT dramatically expands the attack surface
IoT systems do not have well defined perimeters
IoT systems are highly dynamic and continuously evolve because of mobility
IoT are highly heterogeneous with respect to:
Communication
Platform
Devices
IoT systems may include physically unprotected portions
IoT systems are highly autonomous and control other autonomous systems
IoT systems may include “objects” not designed to be connected to the Internet
Human interaction with all the devices is not scalable
IoT dramatically expands our attack surface
This project analyzes the top 10 vulnerabilities in IoT

6. The OWASP Internet of Things Top 10 Vulnerabilities
IoT - Risks
The OWASP Internet of Things Top 10 Vulnerabilities
Insecure Web Interface
Insufficient Authentication/Authorization
Including authentication bypass vulnerabilities in firmware
Insecure Network Services
Lack of Transport Encryption
Privacy Concerns
Insecure Cloud Interfaces
Insecure Mobile Interfaces
Insufficient Security Configurability
Insecure Software/Firmware
Poor Physical Security
IoT dramatically expands our attack surface
This project analyzes the top 10 vulnerabilities in IoT
Examples:
Default username and passwords cannot be changed; weak passwords; hard-coded credentials such as passwords; hidden authentication interfaces
Privilege escalation; lack of granular access control
Buffer Overflow Attacks; DoS
Transmission of unencrypted credential
A device collects more data than necessary
Clouds have many security vulnerabilities
Mobile devices have many vulnerabilities
Lack of granular permission model, lack of password options, no security monitoring, no security logging
Encryption not used to fetch updates; update files not encrypted; update files not verified before upload;
Access to software via USB ports; removal of storage media (this requires making sure that devices cannot be easily disassembled)

7. IoT – Privacy Risks Individuals as sources of multiple data sets
Wearable devices collect huge amounts of personal data as well data about the user environment
Major privacy concerns arise for health-related data from the use of medical devices and fitness applications
Privacy-sensitive information can be easily disclosed to third parties
Threats arise for enterprise perimeters
We are nodes of a global networks

8. Specific Security Challenges of IIoT
We are nodes of a global networks
Diagram from Accenture “Driving the Unconventional Growth through the Industrial Internet of Things”, 2015,
downloaded from

9. IoT – Privacy and Safety Risks
The toy collects information, such as name and age, from the child
A human can ask information to the toy and thus get information about the child – the device does not authenticate the voice of the individual asking the information and thus confidential data can be extracted from the toy if lost or unattended
Insecure key management
Safety
It is possible to inject malicious voice and thus ask the child to do unsafe actions (e.g. open the door)
Slide based on paper by J.Valente and A. A. Cardenas. Security & Privacy of Smart Toys.
In 1st Workshop on Internet of Things Security and Privacy (IoTS&P ’17). ACM 2017.

10. Question: We have a lot of security techniques Can we apply them to the IoT?
We are nodes of a global networks

11. Security Framework for IoT
Prepare and Prevent
Monitor and Detect
Diagnose and Understand
React, Recover and Fix
nesCheck
• static analysis and dynamic instrumentation for nesC memory safety
[ASIACCS2017]
OptAll
• security provisioning based on game theory
[ACM/IEEE IoTDI 2017]
[ACM TOPS 2017]
[ESORICS 2017]
LTEInspector
• systematic testing of 4G LTE
[NDSS 2018]
Kalis
• knowledge-driven adaptable IDS for IoT
[ICDCS 2017]
Heimdall
• whitelist-based anomaly detection defense for IoT routers
[IoT Journal 2017]
Fine-Grained Analysis
• node- vs link-related packet dropping attacks
• interference location
[SECON 2014]
[ACM ToSN 2016]
• statistical model based on variance
[SP4SC (IEEE FiCloud’16)]
Kinesis
• automated response system
[ACM SenSys 2014]
[ACM ToSN 2017]

12. Monitor and Detect Heimdall
D. Midi, A. Mudgerikar, J. Habibi, E. Bertino

13. Mirai Botnet
Mirai is a piece of malware designed to launch multiple types DDoS attacks
The malware scans the internet for telnet servers then attempts to log in and infect them using a list of hard-coded passwords (most of which correspond to internet connected CCTV systems and routers)
A botnets using the Mirai malware was responsible for the largest DDoS attack ever recorded, which peaked at 1.1 Tbps
It exploits well-known hardcoded login credentials in IoT devices
It uses segmented command-and-control which allows the botnet to launch simultaneous DDoS attacks against multiple, unrelated targets
SYN-flooding, UDP flooding, Valve Source Engine (VSE) query-flooding, GRE-flooding, ACK-flooding (including a variant intended to defeat intelligent DDoS mitigation systems, or IDMSes), pseudo-random DNS label-prepending attacks (also known as DNS ‘Water Torture’ attacks), HTTP GET attacks, HTTP POST attacks, and HTTP HEADER attacks
Mirai uses brute force dictionary attacks

14. Mirai Botnet Operations and Communication
Step 1. The bot engages in a brute-force attack to discover the default credentials
of weakly configured IoT devices. There are 62 possible username–password pairs hardcoded in Mirai.
Step 2. Upon discovering the correct credentials and gaining a shell (a command- line or graphical user interface),
the bot forwards various device characteristics to the report server through a different port.
Step 3. Via the C&C server, the botmaster frequently checks new prospective target victims as well as the
botnet’s current status by communicating with the report server, typically through Tor.
Step 4. After deciding which vulnerable devices to infect, the botmaster issues an infect command in the loader
containing all necessary details—for example, IP address and hardware architecture.
Step 5. The loader logs into the target device and instructs it to download and execute the corresponding binary
version of the malware, typically via GNU Wget ( /wget/manual /wget.html) or the Trivial
File Transport Protocol. Interestingly, as soon as the malware is executed it will attempt to protect itself from other
malware by shutting down points of intrusion such as Telnet and Secure Shell (SSH) services. At this point,
the newly recruited bot instance can communicate with the C&C server to receive attack commands. It does so by
resolving a domain name hardcoded in the executable (by default, the value of this entry is cnc.changeme.com in Mirai’s
source code) rather than a static IP address. Thus, the botmaster has the luxury of changing his IP address over
time without modifying the binary and without extra communication.
Step 6. The botmaster instructs all bot instances to commence an attack against a target server by issuing a
simple command through the C&C server with the corresponding parameters such as the type and duration of
attack and the IP addresses of the bot instances and target server.
Step 7. The bot instances will start attacking the target server with one of 10 available attack variations such as
Generic Routing Encapsulation (GRE), TCP, and HTTP flooding attacks.
Diagram from Kolias et al. “DDoS in the IoT: Mirai and Other Botnets”, IEEE Computer 2017.

15. Geo-locations of all Mirai-infected devices uncovered as of October 2016
from I. Zeifman, D. Bakerman, B. Herzberg. Breaking Down Mirai: An IoT DDoS Botnet Analysis. Imperva,
October Available at

16. IoT – Communication “Architectures”
Device-to-device: Two or more IoT devices communicate directly with each other, rather than via an intermediary like an application server.
Device-to-cloud: In this model, an IoT device directly communicates with an application server in the Internet (cloud) and exchanges messages such as devices status and control commands. Connection is via some home gateway.
Device-to-gateway: In this model, an application layer gateway (ALG) is used, which is a computer system with two or more network interfaces. IoT devices are directly connected to an ALG that mediates between the IoT devices and an application server in the cloud.
Device to-Device: Nowadays, this communication model can be seen in home automation applications, in which small data packets are exchanged between devices, such as on/off commands of light switches. Since these devices often have a direct relationship, they usually have built-in security and trust mechanisms, and thus, are not compatible with devices by other manufacturers. Recently, major IoT device manufacturers have established standardization initiatives [24, 38, 45] and are actively establishing open interoperability standards. For device-to-device authentication, for example, the Open Connectivity Foundation (OCF) [38] adopts C-PKI, while Thread [45] utilizes a commissioner device that allows a device to join a Thread network.
Device-to-cloud: In this model, an IoT device directly communicates with an application server in the Internet (cloud) and exchanges messages such as devices status and control commands. Home IoT devices, like the Nest Thermostat [33] and the Lockitron door lock [27], are equipped with a Wi-Fi transceiver and connect to a home gateway in order to communicate with their application servers hosted on some cloud. The application servers collect data from the devices and analyze them to provide more sophisticated services like energy management. Since the application servers are in the cloud, a user can access and control
the devices by connecting to the application servers via his/her smartphone even if he/she is out of his/her house. Like for the device-to-device communication model, it is dicult to integrate devices by dierent manufacturers since proprietary data protocols are usually used between the devices and the cloud services. For instance, it is dicult to implement a system where the house temperature increases and lights turn on automatically when a door lock is unlocked unless all the devices are made by the same vendor. Recently, home IoT service providers, such as Apple [6], Google [19], Amazon [4] and SmartThings [43], have been integrating various home IoT devices made by dierent manufacturers into their proprietary IoT platforms.
3) Device-to-gateway: In this model, an application layer gateway (ALG) is used, which is a computer system with two or more network interfaces. IoT devices are directly connected to an ALG that mediates between the IoT devices and an application server in the cloud. Since the ALG operates application software, it can provide protocol translation and data aggregation, and thus the ALG is dierent from a normal network layer gateway. In this model, IoT devices usually have only short-range radio transceivers, such as Bluetooth, Zigbee and Z-Wave, for energy saving, cost reduction or physical security. Also, the devices typically do not require a persistent Internet connection to their application servers. Some smart door locks [21] and health care
devices adopt this model. A user’s smartphone running an application thus becomes an ALG and the device connects to the smartphone through the Bluetooth interface. Then, the device exchanges messages with an application server in the cloud via the smart phone.

17. IoT Botnet Defense Design
Challenges
Closed devices
Heterogeneity of platforms, OSes, network stacks
Cloud-based load balancing for services
Advantages
High behavioral specificity on average
Anomaly detection does not need complex inference models
No device-to-device communication makes it possible defense at gateway
Consistency allows pre-computed profiles and profile sharing

18. Defense Design Whitelist-based approach
Our analysis shows it is effective
But… naïve design does not work
Separation of learning and enforcement has problems
Profile pollution during learning
Handling firmware updates

19. Defense Design Complex continuous approach is effective
No separation of learning and enforcement phases
Continuous validation of DNS requests
Use knowledge from 3rd party aggregation services
Resilience to DNS Poisoning attacks
Multi-tiered policy enforcement
Real-time validation vs. Max throughput
Instant global blacklisting for subsequently compromised destinations

20. Implementation Hardware & Software VirusTotal
Linksys WRT 1900AC router, running OpenWRT Chaos Calmer
Python custom proxy + IPTables utility
VirusTotal
Free 3rd party security analysis service, aggregating over 60 sources

21. Functional vs. Nominal Whitelist Completeness
Experiment durations
1 hr, 24 hrs, 1 week

22. Heimdall Latency Thus, as seen in
Fig. 3 only the first attempt to connect to the domain incurs
a large overhead. All subsequent requests have minimal overhead
and are within 1% of the query time without Heimdall.
This holds true even if a second device of the same model
(i.e., another Nest thermostat or LifX bulb) is attached to the network, due to the fact that domains have already been vetted.
Therefore, the new device would find its initial communication
streamlined.

23. Heimdall Latency – RTV vs MT
August device
August: smart lock
We did experiments with other devices and the trends are similar

24. Future Research Directions
Mobility-aware Fine-Grained Analysis
Using 2-hop knowledge to construct geometric constraints w.r.t. fixed system of coordinates
Bring-Your-Own-IoT
Enabling containerization and AC policies onto IoT and wearables
Cloud-enabled Heimdall and IoT Identity
Identifying IoT devices by traffic patterns, leveraging identity for cloud repository of policies
Protecting IoT devices from input spoofing
Protecting IoT devices from ransomware
Recent work (see for example recent work by Yongdae Kim) has shown that the “environment” can be manipulated so that sensors acquire false data. For example they have shown that by providing the gyroscope in a drone intentional sound noises, the gyroscope produces un-expected output. In particular, the noise had frequencies equal to the resonant frequencies of the gyroscope. In physics, In physics, resonance is a phenomenon in which a vibrating system or external force drives another system to oscillate with greater amplitude at specific frequencies

25. Thank you!! Any question?