Security analysis and monitoring of smart building technologies and IoT

Texto completo

(1)Graduado Grad ad en Ingeniería Informática Universidad Politécnica de Madrid Facultad de Informática TRABAJO FIN DE GRADO. Security Analysis and Monitoring of Smart Building Technologies and IoT. Autor: Martín Pérez Rodríguez Director: Sandro Etalle (TU/e Eindhoven University of Technology). MADRID, JULIO DE 2018.

(2) Contents 1 Introduction 1.1 Building Automation Systems . . . . . . . . . 1.2 Internet of Things . . . . . . . . . . . . . . . 1.3 Security Landscape . . . . . . . . . . . . . . . 1.3.1 Network Intrusion Detections Systems 1.3.2 SilentDefense . . . . . . . . . . . . . . 1.4 Demo Lab . . . . . . . . . . . . . . . . . . . . 1.5 Contributions . . . . . . . . . . . . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. 1 1 3 4 5 5 6 7. 2 Background 2.1 What is a Wireless Network? . . . . . . Wireless PAN . . . . . . . Wireless LAN . . . . . . . Wireless Ad-Hoc . . . . . Wireless MAN . . . . . . Wireless WAN . . . . . . Cellular networks . . . . . Other Wireless networks . 2.2 What is a Wired Network? . . . . . . . 2.3 OSI Layers . . . . . . . . . . . . . . . . 2.4 Protocols . . . . . . . . . . . . . . . . . 2.4.1 LonTalk . . . . . . . . . . . . . . Protocol Description . . . . . . . Neuron Chip . . . . . . . Known Issues and Vulnerabilities Authentication Process . . 2.4.2 ZigBee . . . . . . . . . . . . . . . Protocol Description . . . . . . . Known Vulnerabilities/Issues . . Discovery attack . . . . . Eavesdrop attack . . . . . Replay Attack . . . . . . . 2.4.3 MQTT . . . . . . . . . . . . . . Protocol Description . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. 8 8 8 9 9 9 9 9 10 11 12 12 12 12 13 13 14 14 14 15 15 15 15 16 16. 1. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . ..

(3) Known Issues and Vulnerabilities . . . . . . . . . . . . . Known Attacks . . . . . . . . . . . . . . . . . . . . . . . Subscription to Wildcards . . . . . . . . . . . . . Preconditions . . . . . . . . . . . . . . . . . Results . . . . . . . . . . . . . . . . . . . . . Description . . . . . . . . . . . . . . . . . . . Prevention . . . . . . . . . . . . . . . . . . . SilentDefense capabilities against the attack DoS as Connect Packet Flooding . . . . . . . . . Preconditions . . . . . . . . . . . . . . . . . Results . . . . . . . . . . . . . . . . . . . . . Description . . . . . . . . . . . . . . . . . . . Prevention . . . . . . . . . . . . . . . . . . . SilentDefense capabilities against the attack DoS as Payload Flooding . . . . . . . . . . . . . Preconditions . . . . . . . . . . . . . . . . . Results . . . . . . . . . . . . . . . . . . . . . Description . . . . . . . . . . . . . . . . . . . Prevention . . . . . . . . . . . . . . . . . . . SilentDefense capabilities against the attack DoS as QoS Level . . . . . . . . . . . . . . . . . . Preconditions . . . . . . . . . . . . . . . . . Results . . . . . . . . . . . . . . . . . . . . . Description . . . . . . . . . . . . . . . . . . . Prevention . . . . . . . . . . . . . . . . . . . SilentDefense capabilities against the attack Identity Spoofing: Credential exposure . . . . . . Preconditions . . . . . . . . . . . . . . . . . Results . . . . . . . . . . . . . . . . . . . . . Description . . . . . . . . . . . . . . . . . . . Prevention . . . . . . . . . . . . . . . . . . . SilentDefense capabilities against the attack Identity Spoofing: DNS Spoofing . . . . . . . . . Preconditions . . . . . . . . . . . . . . . . . Results . . . . . . . . . . . . . . . . . . . . . Description . . . . . . . . . . . . . . . . . . . Prevention . . . . . . . . . . . . . . . . . . . SilentDefense capabilities against the attack Data Tampering and Dangerous Commands . . . Preconditions . . . . . . . . . . . . . . . . . Results . . . . . . . . . . . . . . . . . . . . . Description . . . . . . . . . . . . . . . . . . . Prevention . . . . . . . . . . . . . . . . . . . SilentDefense capabilities against the attack. 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 17 18 18 18 19 19 20 20 20 20 20 20 20 21 21 21 21 21 21 21 21 21 21 22 23 23 23 24 24 24 24 24 24 25 25 25 25 26 26 26 26 26 26 26.

(4) 3 Threat Landscape: Practical Examples 27 3.1 Lighting: the Philips Hue Case . . . . . . . . . . . . . . . . . . . 27 3.1.1 API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.1.2 Security of the platform . . . . . . . . . . . . . . . . . . . 30 Attacking the Hue platform . . . . . . . . . . . . . . . . . 31 Preconditions . . . . . . . . . . . . . . . . . . . . . 31 Description . . . . . . . . . . . . . . . . . . . . . . 31 Attack effects: unauthorized application can access the Hue system . . . . . . . . . . . . . 32 Attack effects: perpetual Alert Mode or forced shutdown . . . . . . . . . . . . . . . . . . . 32 Attack effects: reconfiguration of the platform . . . 34 Final Considerations . . . . . . . . . . . . . . . . . . . . . 35 3.2 Surveillance: Foscam C1 IP Camera Case . . . . . . . . . . . . . 35 3.3 Security of the system . . . . . . . . . . . . . . . . . . . . . . . . 36 3.3.1 RTSP Authentication Vulnerabilities . . . . . . . . . . . . 36 Basic Authorization Mode . . . . . . . . . . . . . . . . . . 36 Digest Authorization Mode . . . . . . . . . . . . . . . . . 38 4 A Solution for BA Protocol Monitoring 4.1 Architecture High Level . . . . . . . . . 4.1.1 SilentDefense Monitoring . . . . 4.2 Architecture Details . . . . . . . . . . . 4.2.1 Protocol Matcher . . . . . . . . . 4.2.2 Protocol Parser . . . . . . . . . . 4.2.3 Asset Information Extration . . . 4.2.4 Detection Algorithm . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. 40 40 41 42 42 43 43 44. 5 Contribution to SilentDefense New Features 5.1 Wireless Support . . . . . . . . . . . . . . . . 5.1.1 Wi-Fi Monitoring . . . . . . . . . . . . Requirements . . . . . . . . . . . . . . 5.2 Philips Hue Lighting . . . . . . . . . . . . . . 5.2.1 HLI Characterization . . . . . . . . . 5.2.2 Potentially Dangerous Operations . . 5.3 LonTalk . . . . . . . . . . . . . . . . . . . . . 5.3.1 LonTalk Matcher . . . . . . . . . . . . Matching Algorithm . . . . . . . . . . 5.4 MQTT . . . . . . . . . . . . . . . . . . . . . . 5.4.1 MQTT Matcher . . . . . . . . . . . . Matching Algorithm . . . . . . . . . . 5.4.2 HLI Characterization . . . . . . . . . 5.4.3 Potentially Dangerous Operations . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. 46 46 47 48 50 50 51 52 52 53 54 54 55 56 57. 3. . . . . . . .. . . . . . . ..

(5) 6 Evaluation & Conclusions 6.1 Wireless Monitoring . . 6.1.1 Goals . . . . . . 6.1.2 Results . . . . . 6.1.3 Future Work . . 6.2 Philips Hue Analysis . . 6.2.1 Goals . . . . . . 6.2.2 Results . . . . . 6.2.3 Future Work . . 6.3 LonTalk . . . . . . . . . 6.3.1 Goals . . . . . . 6.3.2 Results . . . . . 6.3.3 Future Work . . 6.4 MQTT . . . . . . . . . . 6.4.1 Goals . . . . . . 6.4.2 Results . . . . . 6.4.3 Future Work . . 6.5 Conclusions . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. 4. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. 59 59 59 59 60 60 60 60 63 64 64 64 64 64 64 64 67 67.

(6) Abstract Building Automation Systems and the Internet of Things are two IT fields with an exponential growth over the last years. Technology development aims at the era of Smart Cities and interconnection of the common use tools, automating real life tasks and enhancing the quality of services in fields such as Automotion, Home Automation, Industrial Control Systems, health care, energy or finances. Traditionally, BAS and IoT were designed to offer interconnected, working environments to automate the processes while mantaining a reasonable difficulty on deployment and operation. Systems and protocols required also lower levels of security, due to the narrow extent of the Internet, less knowledge on vulnerabilities and the lack of wireless networks. Most of the entry points for malintentioned users were avoided, and professional systems were not easily compromised. Today, the paradigm has changed: while BAS and IoT technologies are still not developing sufficient security measures, threats and exploits are not only a criminal act but a business model. Examples of cyberweapons such as Stuxnet (2010) or BlackEnergy (2015) must raise an interest in security for the new environments, and enable measures to prevent or mitigate the effects of any type of attack. On this report, a passive monitoring solution is described: SilentDefense. The project introduces the work of the author for improving features and compatibilities of the product: Wireless Monitoring, support for several BAS and IoT protocols, and specific threat models for one lighting system and one surveillance system..

(7) Abstract La Inmótica (BAS) y el Internet de las Cosas (IoT) son dos campos de las tecnologı́as de la información que han experimentado un crecimiento exponencial durante los últimos años. El desarrollo tecnológico avanza hacia la era de las Ciudades Inteligentes y la interconexión de elementos de uso común, automatizando tareas cotidianas y mejorando la calidad de servicios en campos como la Automoción, Domótica, Sistemas de Control Industrial, sanidad, industria energética o finanzas. Tradicionalmente, los BAS y el IoT han sido diseñados para ofrecer entornos funcionales interconectados, automatizando procesos a la par que manteniendo una dificultad razonable en instalación y operaciones. Los sistemas y protocolos requerı́an entonces un menor nivel de seguridad, debido al corto alcance de Internet, falta de conocimiento acerca de vulnerabilidades comunes y una práctica inexistencia de redes inalámbricas. La cantidad de puntos crı́ticos explotables por usuarios malintencionados era reducida, y los sistemas profesionales de automatización no eran fácilmente comprometidos. Actualmente el paradigma ha cambiado: mientras que la Inmótica y el IoT se desarrollan sin tener en cuenta unas medidas adecuadas de seguridad, las amenazas digitales y exploits no son sólo una forma de vandalismo digital sino un modelo de negocio. Ejemplos de armas informáticas como Stuxnet (2010) o BlackEnergy (2015) deben servir para generar un mayor interés en la seguridad para los nuevos entornos, ası́ como para la adopción de medidas de prevención y contención para cualquier tipo de ataque. En este proyecto se describe una solución para la monitorización pasiva de redes: SilentDefense. El documento presenta el trabajo del autor, orientado a mejorar las funcionalidades y compatibilidad del producto: Monitorización Inalámbrica, soporte para distintos protocolos de BAS y IoT, ası́ como modelos de ataque especı́ficos contra un sistema de iluminación y un sistema de vigilancia..

(8) Chapter 1. Introduction In this chapter, some information and general lines of knowledge are introduced in order to achieve a correct understanding of the concepts explained in the project. A brief definition of Building Automation Systems and Internet of Things is provided, with a general background of the current status of cybersecurity regarding these fields. In addition, the company SecurityMatters, where this project was accomplished, is introduced along with its monitoring product SilentDefense. A summary of the contribution to SilentDefense concludes the chapter.. 1.1. Building Automation Systems. Building Automation Systems (BAS) are systems designed for automation, management and control of building installations such as HVAC, alarms, lighting or access control. Its main goal is to define automating rules for several aspects of a building or a group of buildings, allowing a more efficient behaviour and interoperability among devices forming the building network. BAS have been developing since the decade of the 1980s, with a special relevance during the 1990s[1] with the appearance of protocols such as BACnet, LonTalk or the fusion of Batibus, EHS and EIB (later resulting in the KNX standard). Today, they are part of professional working buildings and industrial applications, and buildings using BAS are refered as Smart Buildings. Its integration with the Internet of Things, later discussed, define the future of professional facilities, home automation and the city of tomorrow. The main benefits of BAS are: • Sustainability: automating the behaviour of devices can result in a reduced consumption of energy and resources. For example, when the presence of users is not detected in a room, disable the lighting and heating system.. 1.

(9) Figure 1.1: BAS automatable fields [ source: SecurityMatters ] • Simple Management: operators are not forced to apply rules and policies by interacting manually with the devices. • Automatic Responses: effectiveness of certain systems may be enhanced due to automatic reaction to triggered events based on the state of other devices. For example, when a smoke alarm detects fire, inactive elevators automatically interrupt their availability . • Improved building security: operations depend more on deterministic systems and less on the human criterion. • Improved visibility and interoperability: systems are less isolated and depend on a core management system. As opposed, BAS poses major concerns regarding security. Traditionally, classic standards were not designed to be secure, and this reflects in a threat landscape that has been growing since the appearance of Stuxnet in 2010[2], the first cyberweapon designed to target BAS on Industrial Control Systems. In order to guarantee that the benefits of BAS are not shaded by security concerns, the scope of this research is to offer a monitoring solution that can mitigate the possible dangers, as well as preventing the lack of visibility of network traffic. This report will analyze one of the main BAS protocols in the industry: LonTalk. 2.

(10) 1.2. Internet of Things. The Internet of Things (IoT) refers to an IT concept regarding embedded communications on common devices both in the home and industry domain. The idea behind IoT is to deploy everyday items into a low consumption network of sensors and actuators that can interact without human-to-human (H2H) or human-to-machine (H2M) operations. The term IoT was coined in 1999, but its popularity only raised after 20102011, when the expansion of the Internet and a more technological education allowed commercial releases targeting the general public[3]. IoT is a field that experimented a significative growth during the decade, expecting to reach a peak of 31 billion connected devices by 2020, and an exponential increase of usage for the next decade.[4] Acording to Gartner research (2017), IoT will achieve its plateau of productivity in a short term. Figure 1.2 depicts an expectation trend for several IT fields, locating IoT as a promising platform for research and development.. Figure 1.2: Gartner Hype Cycle (July 2017) [ source: Smarter with Gartner ] As a general rule, IoT devices are designed to be lightweight, low consuming, intuitive and versatile. Meeting these requirements is possible after reducing heavy processes, adapting hardware or reducing the contents for the specific protocols. This causes an impact in features such as security, traditionally 3.

(11) ignored or minimized when designing IoT devices. This report will focus on one IoT protocol (MQTT) and one IoT specific product (Philips Hue platform), analyzing their weaknesses regarding security.. 1.3. Security Landscape. As previously mentioned, BAS and IoT are not developing enough security to support its rapid expansion. The situation worsens as the deployment of these technologies into critical infrastructures becomes more common. Stuxnet began a decade of weapons dedicated to industrial facilities and Smart Buildings, interesting from a political, economic or social perspective. A starting point to explain the lack of security in BAS are legacy systems. As a general rule in IT, the vast majority of sysadmins are reluctant to changes in their systems when no precise problems are identified. It is not uncommon to find Windows 95 or XP machines in operational devices, workstations or as the native OS to program a PLC. As a result, classic vulnerabilities are not addressed correctly and systems can be exploited in an unusually easy form for an experienced attacker. Even when using modern devices, preventive actions against known vulnerabilities are not always performed. 2017 approached the concept of ransomware to the general public after WannaCry staged one of the largest massive attacks against several major companies. The attack, which encrypted file systems spreading as a worm, asked for a ransom in order to recover the private key used for the encryption. More than 60 organizations were affected by WannaCry, including bank entities, universities, government facilities, automotion retailers or telecommunication companies. The exploited vulnerability was found in Samba SMB servers, as a well-known issue for which a solution was provided in the last version of the Windows involved machines. Nevertheless, none of the affected companies updated their vulnerable systems one month after the release of the patch.[5] IoT is a recent field of IT, and its youth leads it to be the target of new attackers as vulnerabilities are discovered with a high frequency. Devices tend to be lightweight, avoiding computing costs and features that do not address the intended utility for the user. In addition, bad practises such as protecting the systems with default credentials or simple passwords vulnerable to a bruteforce attack possibilites attackers to work remotely and target systems without a complex infrastructure. An example of this was the Mirai Botnet (2016), developed by a curious undergraduate and affecting IoT systems with a simple username/key pair. The malware scanned devices in service search engines such as Shodan 1 , and tried to access exposed ports using one of 61 possible credential combinations. After a significant amount of devices were compromised, 1 www.shodan.io. 4.

(12) a botnet was stablished and distributed denial of service (DDoS) attacks were launched.[6] Another example of a bad handle of credentials is the Target Incident (2013). The attack involved Target Corp., a department store corporation. In this case, attackers were able to steal information on credit card data, compromising millions of accounts and causing an impact of more than two hundred million dollars on card reissues. The entry point for malware information fetching was a third party vendor, Fazio Mechanical Services, which suffered a phishing attack that compromised the credentials used for accesing Target Corp. network.[7] 2 .. 1.3.1. Network Intrusion Detections Systems. One way of addressing the security issues presented above is by using Network Intrusion Detection Sytesm (NIDS). A NIDS is security solution that monitors network traffic in order to identify threats. This identification can be done using different approaches: • Signature based detection, analyzing known payloads with a recognizable pattern. • Behavioural based detection, learning for the usual behaviour of the networks and alerting after anomalies in the traffic or data. • Whitelisting, allowing certain operations and ignoring the unknown ones. • Blacklisting, banning certain operations while accepting the other ones. The following subsection introduces SilentDefense, a NIDS able to perform monitoring based on this approaches.. 1.3.2. SilentDefense. SilentDefense is a commercial NIDS developed to specifically address industrial network, including building automation networks. It is a complete platform that provides visibility, detection and enhanced control for industrial networks, granting a full view of traffic analysis, statistics and alerts without an active interaction with the network elements. SilentDefense is the flagship product of SecurityMatters B.V., a young cybersecurity start-up based in the Netherlands and the United States. Since 2009, SecurityMatters has provided services to customers and partners belonging to several industries, including power generation, energy and water distribution, oil and gas, and the finances.[8] 2 Facts exposed about the initial infection of Target Corp. are not fully proven. Nonetheless, the theory exposed is the most accepted by experts and analysts.. 5.

(13) Functioning of SilentDefense is detailed in Chapter 4. An example of the SilentDefense Dashboard while deployed on a network is provided on Figure 1.3 .. Figure 1.3: SilentDefense Command Center. 1.4. Demo Lab. SecurityMatters R&D team owns a networking lab for experimentation purposes. Researchers can use it for live traffic generation, malware analysis, attack simulations, SilentDefense alert testing and other tasks involving the evolution of SilentDefense and the general knowledge of the company. The lab is also used for demonstrations and presentations to partners and potential customers. While the SecurityMatters lab features several tools for the analysis of BAS and IoT, the following devices have been relevant for the scope of this project: • Raspberri Pi 3. Used as an attacker machine. Several scripts are stored and executed against other devices or the entire network. • Philips Hue Starter Kit. Attacks and research on Philips Hue have been developed using a Philips Hue Bridge, and one smart white light. • Windows 7 Virtual Machine. Useful for achieving a virtualization that emulates a real PC, without compromising the host machine or exposing the lab. 6.

(14) • Ubuntu Server machine adapted to a SilentDefense installation. It provides the following services: – SilentDefense Sensor Module – SilentDefense Command Center • Foscam C1 IP camera (simulation of a simple surveillance system). • Developer Virtual Machine. Used for developing matchers and other code relevant for the following versions of SilentDefense.. 1.5. Contributions. This report is based on a six month work in SecurityMatters, with the objective of enhancing the features and compatibilities of SilentDefense. After this period, the following tasks have been implemented: • Enhancing SilentDefense in order to support monitoring of Wi-Fi traffic. This will help SilentDefense to deal with IoT devices. • Philips Hue analysis: providing support to the identification of assets and threats related to the Philips Hue platform. • LonTalk protocol support: providing support to the monitoring of the LonTalk protocol. To this end, a matcher and a protocol parser has been developed in order to perform analysis and threat detection for devices of the LonWorks family. • MQTT protocol support: providing support to the monitoring of the MQTT protocol. To this end, a matcher and a protocol parser has been developed in order to perform analysis and threat detection for devices of the LonWorks family. Chapter 5 details the provided contribution from a more specific perspective.. 7.

(15) Chapter 2. Background On this section, background learnt during the project is presented. In order to build a solution for the contributions previoulsy introduced, general knowledge about the following topics is provided: Wireless Networks, LonTalk, Philips Hue and MQTT .. 2.1. What is a Wireless Network?. A wireless network is a computer network that uses non-guided connections between nodes. Wireless networks are rapidly proliferated and they are key enablers for Smart Buildings, Home Automation, Internet of Things or Intelligent Vehicle technologies. Together with the great benefits they provide, they also pose major concerns on the threat landscape of network security, allowing attackers to actuate remotely and, in many cases, without a prior physical access to target devices. Examples of attacks that can be carried out against wireless network include Packet Sniffing, Rogue Access Point, Password Theft, Man-inthe-Middle attacks and Jamming. Wireless Networks are a wide field of knowledge. Practically all communications where no guided media is involved can form a wireless network. For a correct understanding of further documentation, a brief summary on each type of wireless network is provided in this section. Classification must be done according to the range and scope of the network.[9]. Wireless PAN Wireless Personal Area Networks are wireless networks used in the range of a single person reach. They can interconnect several devices, such as Bluetooth communications between a phone and a microphone/speaker system installed in a car. Computer mouse communications to a USB receptor are also an example of a WPAN. Some protocols involved in WPAN are Bluetooth or infrared systems, but also IoT protocols such as ZigBee or KNX.. 8.

(16) Wireless LAN Wireless Local Area Networks are used for local, simple communications over own networks or as a low-layer network in order to connect to other high level network by using a gateway. They are the lowest in range after WPAN, usually being only available at one or few people reach. The most common use case for a WLAN is a home or office setup with several devices such as laptops or phones forming a private network, which is connected to a router with a WAN access. The core node of WLAN networks is usually an Access Point, where all the communications are set and managed.The most common protocols used on WLAN are the Wi-Fi 802.11 family.. Wireless Ad-Hoc Also called peer to peer networks, they use a mesh structure in order to achieve communication among devices without a central device such as an Access Point. They avoid dependency on other nodes, every node performs routing, and every node is resilient to power loss or unavailability.. Wireless MAN Metropolitan Area Networks can be simplified as the interconnection of several WLAN. They are networks where the range is more extended, usually a district or a town. WMAN are used for the efficient implementation of systems such as municipality surveillance cameras, interconnection of institutional networks over several buildings; but also used by ISPs to serve a determined geographical region. WiMax is a common standard for WMAN networks.. Wireless WAN Wide Area Networks are used to connect several networks over the scope of cities, large distances and even countries. Applications are numerous, including: • LTE networking to provide Internet access on smartphones. • Virtual networks over VPN • Mailing or chat systems. Every device that requires a non-guided Internet connection to communicate with a remote address is part of a WAN. Cellular networks Also called mobile networks, since it is the technology used by mobile phone communications. They are radio networks where a transceiver is set for providing services to a determined geographical place, and each one of them generates a zone called cell, where the transceiver is used. 9.

(17) by the nodes present in that region. If one of the nodes exits the cell, it will search for the conrrespondent transceiver on the current location. Devices can communicate via those transceivers to reach other nodes even on remote cell zones.Cellular networks are not only used on mobile phone calls, but also for carrying data generated by recent devices such as smartphones. Some of the most known protocols are GSM (Global System for Mobile Communications) or PCS (Personal Communication Service). Other Wireless networks There are other types of specific wireless networks. One of them is GAN (Global Area Network), where the aim is to contain an arbitrary number of wireless network systems and permit communications among their devices over remote geographic zones of actuation. Another examples are Space Networks, used by Space Agencies for communications on Earth proximities; or Deep Space Networks, used to communicate with devices that are set in the deep space.. 10.

(18) Figure 2.1: Protocol classification on data rate and power consumption. 2.2. What is a Wired Network?. Wired networks are those using guided media for data transporting. It is the classical method for implementing communications among devices, requiring physical connections attached to all the elements in the network. Wired networks are currently the only solution in critical infrastructures and sensitive topologies due to security reasons. Accessing to a wired network requires a physical presence, and intruders may need to gain access to a specific. 11.

(19) building or room in order to perform actions against the network. Nonetheless, they present disadvantages such as the lack of versatility and flexibility present in a wireless network. On a mid to long term basis, it is predictable that wired networks will decrease in relevance due to the rise of IoT and smart devices. Wired networks are currently the most common option for Building Automation Systems, Industrial Control Systems and other automation solutions.. 2.3. OSI Layers. Figure 2.2: OSI Stack for several Wireless Protocols. 2.4 2.4.1. Protocols LonTalk. Protocol Description LonTalk[10] is a networking protocol designed for LonWorks, a platform that provides a set of resources for Building Automation and control of elements such as HVAC or lighting. LonWorks belongs to Echelon Corporation, who submited the networking communication protocol in 1999 (later known as LonTalk), and was accepted as a stardard since then. The LonWorks-based communication protocol is one of the most widely deployed technologies worldwide despite being a propietary platform. This is due to its relative low cost, an open specification and a great compatibility with other manufacturers devices. LonTalk conforms to ISO/IEC 14908, EN 14908, ANSI/CEA-709/852 and is also standardized in China. This protocol actuates similar to a LAN, and in fact, LON stands for Local Operating Network.. 12.

(20) LonWorks is suited for use with different types of transmission media, such as twisted pair cables, power line, RF, fiber optics or IP (both TCP/IP and UDP/IP), which provides a wide range of options for L1. It is important to mention that, even if LonTalk redefines the OSI stack layer, a large number of LonWorks applications have a full compatibility with IP based networks. The tunneling standard ISO/IEC 14908-4 is used in LonWorks in order to offer this compatibility: IP-aware systems can be integrated with new LonWorks applications or network management tools. Other applications related to the platform offer interactive compatibility by using resources such as Web Services or IP-routing. Neuron Chip One of the core concepts regarding LonWorks is the Neuron chip[11]. A Neuron chip is an integrated circuit included in every LonWorks device, and offers the protocol a hardware environment for its execution and treatment. Neuron Chip is an 8-bit processor actuating as a 3-in-one microcomputer: two of the microprocessors are used for the communication protocol, and the last one is used for the node control application. This way, Neuron guarantees a better optimization of the internal operations for LonWorks and this is translated in a relief of the computational cost for the network response. LonTalk protocol is the main competitor of BACnet[12] in Building Automation. In an attempt to increase the flexibility of both the protocols, since 2014 it is possible to use BACnet over LonTalk. This extends BACnet capabilities making possible to use it along all the automation processes. Improvements are not only achieved in compatibility, but also in the features for Building Automation that both protocols have to offer. Known Issues and Vulnerabilities One of the first issues regarding LonTalk security is that the protocol does not run any means of encryption. It is possible that Echelon does not consider a matter of concern that packets are sent in plain text. Authentication is performed on the sender side, requiring every request to be authenticated with a key that proves the original source as a trustful sender[13]. This key is set on installation and stored into the Neuron chip of the device, and it must never be leaked from the chip. Keys must comply to the following requisites: • A key must never be leaked outside of the chip. • A key cannot be modified unless the original key is known. • Every node in the network must be aware of other devices keys for authenticated communications.. 13.

(21) Authentication Process Pre-requisite: Alice knows the key for Bob, and Bob knows the key for Alice. 1. Alice sends a random 64bit number to Bob. 2. Bob receives the challenge, which should be replied transforming the random number based on its private key. 3. Alice repeats Bob process with the same key. 4. If the challenge and the internal computation match, then the authentication is performed succesfully. Note that during this proccess keys are never exchanged through the network. Figure 2.3 depicts the authentication process for LonTalk.. Figure 2.3: LonTalk Authentication. 2.4.2. ZigBee. Protocol Description ZigBee[14] is the specification of a protocol family based on IEEE 802.15.4, for low rate Wireless Personal Area Networks (LR-WPAN). Its main goal is to provide a low consuming, low resource oriented communications among devices in a mesh network. It is defined as a low tier, ad hoc, terrestrial, wireless standard (Magne Tjensvold, 2007). As ZigBee provides an easy integration with small components that do not require many electronics, its main fields of application are Home Automation and IoT. ZigBee is a versatile specification used in home entertainment, home security/control, industrial monitoring, sound engineering (wireless microphones), sensing, medical data collection, or warning systems for smoke, presence, light and movement.. 14.

(22) A difference among IEEE 802.15.4 and ZigBee must be established. While IEEE 802.15.4 is a protocol that serves as the basis for several specifications (like, for example, Thread or 6LoWPAN), it defines the way these protocols will work on L1 and L2. The protocol stack range for ZigBee goes from L3, since it defines an independent way of communication among its devices at network level; to L7, since it provides several layers of application based on the different ZigBee profiles that exist as well as a security application layer). Known Vulnerabilities/Issues One of the most useful resources in order to get an introduction on ZigBee attacks is the paper Three Practical Attacks Against ZigBee Security (Olawumi et al., December 2014)[15]. In the paper, three different attacks are combinated in order to pose a threat model that can be used for security testing purposes. Discovery attack The attacker tries to discover al ZigBee based enabled networks as well as their configurations. It is not harmful by itself, but it is often the prerequisite to launch other attacks that cannot take place without a previous knowledge of the target. Eavesdrop attack The attacker uses the information retrieved in the first attack mentioned before, and can listen to unencrypted or encrypted communications among ZigBee devices looking for sensitive information. Replay Attack It was possible to replay forged request without using a Manin-the-Middle scenario. This way, the attack gains simplicity on implementation, and detection is not as trivial as in the MitM case. ZigBee has gained the attention of white hackers and security experts. Security frameworks for ZigBee testing have been developed over the last years, being KillerBee the most known option. Written by Joshua Wright in 2014, it is a Python based tool that allows a user to sniff, replay and analyze ZigBee packets when a 802.15.4 compatible network interface card is installed in the host system. KillerBee is a native tool in Kali Linux, but it can also be installed in other UNIX compatible OS with no costs (free software under a BSD license). A guide on KillerBee can be found at the Kali Tools documentation. The flagship attack regarding ZigBee is the one explained in the paper IoT Goes Nuclear: Creating a ZigBee Chain Reaction (Ronen et al., 2017)[16] . Authors explain how a worm that bypasses all the built-in security measures on the ZigBee Light Link profile can infect several devices and spread by itself, avoiding legit users to take control of their lights and potentially causing a blackout when the number of devices that are physically close is high enough. Since the attack was performed using the Philips Hue lighting system, the company actuated after the paper release in order to patch the security flaws exposed on the publication. Even that the attack is currently deprecated for newer versions of the. 15.

(23) firmware, it shows how IoT can become significantly dangerous when security is not developed and implemented correctly.. 2.4.3. MQTT. Protocol Description MQTT (Message Queue Telemetry Transport)[17] is an L7 protocol, defined by its authors as a lightweight messaging protocol for small sensors and mobile devices, optimized for high-latency or unreliable networks. This protocol is widely used for M2M communications and it is one of the most known protocols in IoT. Its simplicity, and its reducted consumption of resources, makes it an interesting protocol for small devices, sensors, microcomputers and other embedded machines. MQTT defines a star topology ( Figure 2.4 ), managed by a central node called broker. In order to keep alive the communication channel, every device sends periodically a ping request (PINGREQ) that is answered by the broker with a ping response (PINGRESP). A single broker can manage up to 10.000 devices.. Figure 2.4: MQTT star topology. 16.

(24) Communication is performed complying to a publisher-subscriber model. One client can publish a topic, and others can subscribe to it. Cardinality can be 1:1 or 1:N, but never N:N, since the same topic cannot be published by more than one unique client. Topic addresses follow a tree structure that reminds the directories of a UNIX machine. For example, a topic can be located at building/floor3/room2/raspberry5/temperature. Clients can interact with the topics they are subscribed to, establishing MQTT as suitable for a wide range of applications: home automation, chat clients, meteorological sensing... Some major companies in IT use MQTT for services such as Facebook Messenger, Amazon IoT, Microsoft Azure or Pimatic for Raspberri Pi. Known Issues and Vulnerabilities MQTT offers no security measures . This is not a flaw nor a mistake from their developers: the protocol is meant to be light, and operations such as encryption are costly in computing terms. MQTT can offer a layer of authentication by giving users the chance to set a username:password pair of credentials. However, it cannot ensure the secure sharing of them if no measures are taken under L7. It is encouraged that, for applications that require some level of secrecy, TLS/SSL or any other protection methods are used, although the resource consumption of the network may be negatively affected. Non-encrypted communications are vulnerable by design if important information is disclosed on payloads. MQTT can reveal to a sniffer the type of messages exchanged, topics, values or even credentials ( Figure 2.5 ).. Figure 2.5: Credentials shared in plain text Attacks to non-secured MQTT connections are not difficult to implement and can be even automatized by using MQTT libraries on a scripting language. Two of the most used libraries for MQTT are Paho and Mosquitto (Python). 17.

(25) They can be used to set up MQTT services (as a Broker or a Client), and generate MQTT traffic among devices. Possible attacks against MQTT are classified as Denial of Service, Identity Spoofing, Information Disclosure, Elevation of Privileges and Tampering Data.. Figure 2.6: MQTT Threat Model. Known Attacks Design of MQTT poses several attack scenarios affecting privacy, availability and authorization. In this section several threat models for MQTT will be discussed, including what are the prerequisites for an attack, what is the outcome, how to perform the attack and a proposal of preventive measures. Subscription to Wildcards Attack against the publish-subscriber design aiming at information fetching in the MQTT Broker.. Preconditions • The attacker holds an MQTT client that can reach the broker (over the same network or on a public IP address). • The broker does not blacklist interaction with wildcard identificators # or +.. 18.

(26) Results • The attacker gains access to the topics and structure of the broker • Every time a publish message is sent to the broker, the attacker will see it as a regular subscriber • The attacker can publish on existing or new topics Description MQTT works on a publisher-subscriber schema. Any authorized client may suscribe to a publisher topic, or publish their own topic. If that topic does not exist, it is created. For example, Alice can suscribe to a new topic called /basement/cameras/3 . Then Bob can publish something on that topic, and Alice will receive the message. Since the posible options are virtually endless, an attacker cannot identify the system structure unless information fetching and recognition is performed. However, MQTT poses a high risk concern: subscriptions can be made using wildcards that refer to existing topics in the broker. There are two types of wildcard on MQTT: • Multiple Level ( # ): Refers to all the topics under a level of the tree. A subscription to /building/groundfloor/# will subscribe to: /building/groundfloor/kitchen/temperature /building/groundfloor/kitchen/humidity /building/groundfloor/livingroom/temperature A subscription to /building/groundfloor/# will not subscribe → to: /building/firstfloor/kitchen/temperature • Single Level (+ ) : Refers to all the topics of a single level of the tree sharing the same termination. A subscription to /building/groundfloor/+/temperature will → subscribe to: /building/groundfloor/kitchen/temperature /building/groundfloor/livingroom/temperature A subscription to /building/groundfloor/+/temperature will → not subscribe to: /building/groundfloor/kitchen/humidity. 19.

(27) /building/firstfloor/kitchen/humidity /building/groundfloor/kitchen/fridge/temperature. Prevention It is possible to configure MQTT networks for ignoring this type of requests. Legit devices must know by default which are their topics and avoid suscribing to wildcards. SilentDefense capabilities against the attack A SilentDefense script may raise an alert when a request is performed against # or /+/ . DoS as Connect Packet Flooding MQTT is specially vulnerable to DoS attacks. Since it is usually deployed over TCP, it requires acknowledgment messages that can exhaust the resources of the broker when the amount of petitions is large enough. Nonetheless, sending random messages in a short period of time is not the most efficient way to perform the attack. Connect packet flooding, Payload Flooding and QoS Level can enable DoS in a reduced amount of time and packets. Preconditions • The attacker holds an MQTT client that can reach the broker (over the same network or on a public IP address). Results • The broker resources are exhausted causing a service malfunction Description When a broker receives a Connect packet, a new MQTT session is attempted to initiate. During this process, there are several resources that are shared by both parts, and the broker has to decide whether the Client is allowed to establish a connection or not. Sending several CONNECT packets within a short time frame may cause a malfunctioning of the service. For implementing this attack, only a script and an MQTT client is required. The algorithm of the program can be an infinite loop, executing on one or several machines that attempt a connection to the broker. Prevention. Resilience against Denial of Service attacks:. • Firewall policies against DoS • Rate limiting clients • Distributed MQTT brokers • Application layer firewall: monitoring and block anomalies 20.

(28) SilentDefense capabilities against the attack SilentDefense may raise an alert when an unusual amount of connections are attempt in a short time frame. DoS as Payload Flooding Preconditions • The attacker holds an MQTT client that can reach the broker (over the same network or on a public IP address). • A connection has been established among the attacker and the broker • If the broker requires authentication, the attacker is properly authenticated, either with a spoofed illegitimate client or with the credentials of a legit user. Results • The broker resources are exhausted causing a service malfunction Description MQTT is designed for supporting heavy payloads, up to 256 MB. A malicious user may flood the broker rapidly in a short time, sending requests that contain a large amount of data. Prevention Resilience against Denial of Service attacks as mentioned in Connect Packet Flooding . SilentDefense capabilities against the attack SilentDefense may run a sensor script that identifies payload sizes and alerts when an unusual amount of data is sent from a client to a broker. The average size of an MQTT payload rarely exceeds the kB: this means that a reasonable, small threshold must be defined by default. Customers that require larger payload averages shall modify this value. DoS as QoS Level Preconditions • The attacker holds an MQTT client that can reach the broker (over the same network or on a public IP address). • A connection has been established among the attacker and the broker Results • The broker resources are exhausted causing a service malfunction 21.

(29) Description. MQTT supports Quality of Service (QoS) levels from 0 to 2.. QoS Level 0 (Fire and Forget) allows the client to send an MQTT packet without requiring an acknowledgment on L7. Only guarantees from TCP shall be assumed.. Figure 2.7: Quality of Service Level 0 [ source: HiveMQ ] QoS Level 1 (At Least Once) requires the acknowledgment of every request a client performs, in the form of ACK packets (for example, a publish acknowledgment message is known as a PUBACK).. Figure 2.8: Quality of Service Level 1 [ source: HiveMQ ] QoS Level 2 (Exactly Once) requires that every packet is received only once by the other part. Data is stored until it is guaranteed that the other part has received the message, then it is discarded for preventing duplicates. In order to achieve this, three types of packet must be used in the process. 1. Confirmation of the request (REC). The sender discards the original request (in the picture, a publish request). The receiver stores a reference to this data. 22.

(30) 2. Response to the acknowledgment (REL). The sender confirms the deletion of the original reference to the packet. The receiver deletes its stored references to data, and sends a COMP message. 3. Completion (COMP). The receiver confirms to the sender that all data has been removed, and the exchange ends.. Figure 2.9: Quality of Service Level 2 [ source: HiveMQ ] Any DoS attack can be enhanced by requiring QoS. In the case of Level 2, resources must be stored in the broker until they are delivered to all suscribed clients, causing an increase on the usage of the network resources. This fact can be combined with a massive sending of packets to gain efficiency during the attack performance. Prevention The ”Exactly One” mode should be used only under special circumstances. In many cases, avoiding the support for QoS 2 is a correct approach. SilentDefense capabilities against the attack A SilentDefense script may analyze the QoS field of MQTT packets, and raise an alert when excessive requests for QoS 1 or 2 are detected. Identity Spoofing: Credential exposure While authentication is not required for all MQTT networks, it is common to set protective measures in order to avoid non-authorized devices to perform operations in the system. This is usually implemented by defining credential pairs in the form of username:password. As previously introduced in Figure 2.5 , credentials can be exposed when security measures are not offered, allowing a device to impersonate another node or user in the network. Credentials are not the only option for impersonating legitimate devices. DNS Spoofing exploits the MQTT system for translating domain names into IP. 23.

(31) addresses, enabling a Man-in-the-Middle attack where a malicious device can actuate as a broker impersonating the existing one in the network. Preconditions • The attacker holds a client that can reach the broker (over the same network or on a public IP address). • The attacker is on the same network and/or is able to sniff traffic in promiscuous mode. • MQTT traffic is not running any kind of encryption. Results • The attacker is able to impersonate a legit user. • The attacker is able to perform actions in the system, within the privilege level of the impersonated user. Description On MQTT networks, a Client ID is required by default for any Client service. In addition, credential pairs of username:password may be used to improve the overall security of the system. Nevertheless, when MQTT runs with no encryption, this information may be disclosed on sniffing. Then an attacker will be allowed to interact with the network as an authenticated user. One possible scenario for this exploit may be the following sequence: 1. A malicious user introduces a device on a network with MQTT services available. 2. The attacker sniffs the network in promiscuous mode and searches for MQTT traffic. 3. Client ID and credentials of any user are disclosed and seen by the attacker. 4. The attacker connects to the broker using the previous information. Prevention This attack is completely denied when the traffic is over TLS. The usage of certificates can also identify clients and servers and complicates the impersonation of a legit device. SilentDefense capabilities against the attack SilentDefense can raise an alert when MQTT payloads contain labels such as ”username”, ”password” or any other dangerous identificators. For a better flexibility, the detection pattern has been implemented by using regular expressions. Identity Spoofing: DNS Spoofing. 24.

(32) Preconditions • A vulnerable DNS Service is running on the network. • The attacker is able to set an illegitimate broker on the network. • (Optional) The attacker is able to set its own DNS service on the network. Results • Redirection of the MQTT traffic to a malicious broker. • The attacker is able to analyze and steal information from the redirected packets. • Enables a potential reply attack on the network, even when traffic is encrypted. Description MQTT features a service called FQDN (Full Qualified Domain Names). Its function is to actuate as a DNS service, which is able to translate one domain name into an IP address. FQDN authentication might be compromised according to several scenarios such as credential stealing, bruteforce attacks or a human misuse. If FQDN is compromised, an attacker can configure the service for causing a packet redirection to a malicious broker. Alternatively, an attacker may achieve the same outcome after setting its own DNS service on the network. For a correct understanding, an example scenario is provided below: 1. An attacker is able to deploy a device that works as an MQTT broker. 2. The attacker is able access to the FQDN services after authentication has been bypassed due to a default configuration. 3. The attacker configures the service for redirecting traffic to the malicious broker. 4. After DNS translation, MQTT traffic is intercepted by the malicious broker. The attacker is able to store publish packets about the status of a smoke detector. 5. After a period of time, packets are constantly replayed to simulate the non detection of smoke. Alarms will not trigger in case of a fire. Prevention Network monitoring may identify unknown devices running MQTT or DNS services. For static networks, IP whitelisting allows the system to ignore services that are not run on a well known device. Policies for detection of Man-in-the-Middle attacks can expose illegitimate brokers or devices.. 25.

(33) SilentDefense capabilities against the attack A SilentDefense script may raise an alert whenever a client sends a request to an non-whitelisted IP address. It may also send an alert after discovering a service that was not provided by the network administration Data Tampering and Dangerous Commands Preconditions • The attacker is on the same network or is able to interact with it. • The attacker can intercept messages or forge them. • The attacker has sufficient authorization level so the broker accepts its messages (or the broker does not run security measurements). • The attacker has a sufficient knowledge of the MQTT service. It is able to understand the possible messages that will cause an impact. Results • The attacker is able to perform actions in the network. • The attacker may be able to interact with IoT elements that depend on MQTT: lights, sensors and other actuators may be exposed to a non desired usage. Description Some IoT components actuate based on the updates that they receive from a publisher. For instance, if the last update of a publisher states ”LIGHTS: ON”, the controller may send a command to all the lights in the room to switch on. If a user is able to forge, or tamper the content of a legit message, undesired actions may be performed on the system. This attack may be combined with other previous attacks discussed on this threat analysis. Prevention Use of message integrity checks combined with the encryption of the traffic on transport layer (TLS). Certificates such as X.509 can help to identify legitimate Clients and Brokers, ignoring the traffic from unknown sources. SilentDefense capabilities against the attack A custom SilentDefense script can be written for a particular MQTT network, and raise an alert after identifying any potentially dangerous commands and sources.. 26.

(34) Chapter 3. Threat Landscape: Practical Examples In this chapter, practical examples of vulnerability exploits are offered. All the attacks implemented have been studied and executed in the Demo Lab of SecurityMatters. The project has focused on lighting, exploiting the Philips Hue vulnerabilities in order to build an attack set and understanding the functioning of the system for a correct monitoring. Additionally, research on surveillance IP camera systems has been done, using a Foscam C1 camera and targeting the RTSP protocol.. 3.1. Lighting: the Philips Hue Case. Hue is an innovative smart-lighting platform designed by Philips 1 . The main idea behind it is to introduce the power of IoT at the home domain, providing both an easy installation and a friendly interaction with the user. Its first version was introduced in October 2012, as the first general IoT environment that was possible to control by using a smartphone. It was designed to be a simple, yet a powerful environment, with numerous useful applications. The system also encourages third party developers to build an publish their own applications under the Open Source principles. Currently, Philips Hue last release is on its third generation of products (October 2016). Hue offers Starter Kits in order to make the change to smart lighting easier for non-experienced users. The White Light starter kit is available at SecurityMatters lab, consisting on: • One Philips Hue Bridge • Three white light smart bulbs. 1 More. information at www2.meethue.com. 27.

(35) • One remote control dimmer Philips also offers a starter kit with RGB lights, but it is considerably more expensive and not interesting for research purposes. Lights do not require a connection to the Internet or to an offline router. Even when there is no access to it (for example, a malfunctioning or a network failure), lights can be used as regular bulbs. They can be connected in the same way as non-smart lights and controlled by a classical switch. Nonetheless, the capabilities for them are limited: schedules, rules, scenes and triggered events from a sensor will not work. Light features, such as dimming or color change, will be only possibe by using the remote control included with the starter kits. The official Hue app for Android or iOS will guide the user in order to make the first installation of the products. The Bridge must be connected to a router. Connection to the Internet is optional, but without a WAN connection users can only send commands to the system while they are in the same network. Any other Hue device is usually discovered during the installation automatically. Communication with the Bridge is done via Ethernet (usually, Wi-Fi). On the field side, the Bridge translates any API request to ZigBee Light Link (ZLL) commands, being the protocol used for direct communication among lights, sensors and other Hue devices. A scheme of a typical Hue network is depicted in Figure 3.1. Figure 3.1: Taxonomy of a Hue System deployment. 28.

(36) 3.1.1. API. One of the most attractive feature about Hue is the existence of an open API, which grants any developer a free access to educational content about how to develop third party applications using Philips official documentation. Hue encourages freelance developers to release new content, expanding the features of the official app for multiple platforms (Windows, Linux, Mac, iOS, Android, Windows Phone...). On the other side, it is not required to develop a front-end app to interact with a Hue system. If the Bridge is a reachable device from a network, users can start interacting with it in any way they are able to send RESTful requests to that Bridge IP address. We have coded a simple Python script on our Raspberri Pi, using the Python library requests and SenseHAT, in order to use the built-in HAT joystick as a switch for the light. Steps for manually generating an authorized user in the API[18]: 1. Find the IP address of the Bridge. The Bridge will appear as a network device on the router management website. Alternatively, it is possible to use network scanners in order to discover the address. 2. Open a web browser and search for: http://<bridge ip address>/ The main page of the Bridge should appear on screen. Introduction to the system, several developer resources and legal information are explained. If this website is running, the access to the Bridge API is guaranteed. 3. Access the REST client typing: http://<bridge ip address>/debug/clip.html 4. In order to get access to all Hue functions, an API key is required. This will enable any user or application to be permanently whitelisted to the API and perform actions on the system. When using a front-end application, users will be required to push the Bridge link button in order to authorize the registration. This generation can be also done manually. First step is to press the link button on the Bridge. Then, on the URI root, users should perform a POST request with the following payload: {"devicetype": "appname#devicename"} In case the link button is not pressed before performing the request, the response will contain a message error informing that the link button should be pressed before a hash generation. This is the only protection mechanism the system runs in order to authenticate a client.. 29.

(37) 5. The response must show a success message with a hash. The hash must be stored and not lost, since a REST client with raw messages is being used. Applications automatically save it so users may not even be aware of its existence. [{"success":{"username": "83b7780291a6ceffbe0bd049104df"}}] From now, an API request will have the following URI structure: /api/<hashed_username>/<resource> From this point, several requests can be performed to the API • All the information about the Hue Bridge (state of devices, stored authenticated keys, rules, behaviours...) GET http://<bridge ip address>/api/<hashed_username> • Switch on a light bulb PUT http://<bridge ip address>/api/<hashed_username>/lights → /<number>/state Payload {"on":true}. 3.1.2. Security of the platform. Philips Hue was designed to be a simple, user-friendly and highly versatile environment. Although these goals were achieved since the first version of the products, several risks and a lack of security by design are still a matter of concern on the system. An open API is a critical entry point for exploits, since every vulnerability is exposed to automation and abuse by developing malicious apps or scripts. Fortunately, to gain the control of a Hue system, reaching the Bridge IP address is not the only condition. In order to authenticate a new client, the central link button of the Bridge has to be pressed during the hash generation. This will a priori guarantee that the authorization requester has physical access and is present in the Hue installation. As mentioned in the previous section, the link button is the only protection mechanism to avoid intrusion, and it was found vulnerable after the analysis and study of the environment. Communications on the Ethernet domain are in the form of HTTP requests with no encryption. Moreover, every interaction with the API that requires a key hash (such as dimming lights or change a configuration) discloses: 30.

(38) • The full URI of the request, including the key hash. • The REST method (GET, PUT, POST, DELETE). • JSON Payload, if any. • Content of the Bridge response. The following attack models will be focusing on the Ethernet network, which is found to be the most vulnerable part of this technology. Attacking the Hue platform When sniffing traffic of a network where a Hue installation is running, the disclosed information may allow a malicious user to gain unauthorized access to the system. After a succesful attempt of this attack, it is possible to perform any action that a legit user is able to do without a physical access to any device. Preconditions • A reachable Hue Bridge • Hue Traffic of the network where the Bridge is deployed • The attacker is able to sniff that traffic using promiscuous mode Description steps:. Information about the system can be disclosed in two simple. 1. The attacker performs a sniffing in promiscuous mode. It is possible to identify the traffic that is directed to the Bridge: a RESTful request against the Hue API in the form of http://<bridge-ip>/api/<hash>/ Any request (GET, PUT, POST, DELETE) will reveal the hash. For a better understanding of the explanations, the following example setup is presented. Note that the information for this step is obtained after sniffing traffic in order to get the API packets. • A Bridge located at 192.168.1.10 • An authenticated user with the hash fLuJSBZbU5ioD5VxQgbbwvawdghLP5oui3POXOrj 2. The hash will be used for impersonating an authenticated application or user. The attacker can open a web browser and retrieve information about the system. With the example data, this is how the URL must be called for consulting the information about lights, configuration and sensors respectively (see Figure 3.2).. 31.

(39) http://192.168.1.10/api/ → fLuJSBZbU5ioD5VxQgbbwvawdghLP5oui3POXOrj/lights http://192.168.1.10/api/ → fLuJSBZbU5ioD5VxQgbbwvawdghLP5oui3POXOrj/config http://192.168.1.10/api/ → fLuJSBZbU5ioD5VxQgbbwvawdghLP5oui3POXOrj/sensors After all the required information is revealed, the attack is considered succesful and any desired operation can be performed. Attack effects: unauthorized application can access the Hue system Whenever a new application must be whitelisted to the Bridge, the system asks the user to phisically push the link button in the Bridge surface. This is a security measure that prevents a user to authorize wireless clients without being near the device. Surprisingly, the link button state is only a JSON boolean parameter that can be modified with a RESTful request, providing that it is done with an authorized hash. When an attacker is in posession of this hash, it is possible to authorize any application and use it in the system, including the Philips Hue Official App. The virtual pushing of the link button can be scripted in Python as follows: import json, requests url = ’http://192.168.1.10/api/ → fLuJSBZbU5ioD5VxQgbbwvawdghLP5oui3POXOrj/config’ payload = {’linkbutton’: True} headers = {’content-type’: ’application/json’}. r = requests.put(url, data=json.dumps(payload), headers=headers) The attacker has to run this script (or send the petition through the RESTful client provided by Philips) when the application asks the user to push the Philips button for authorization. A more extreme variant of the exploit may be an infinite looping of the link button request every 20 seconds, making the Hue Bridge completely open and vulnerable to any application that is trying to access the system. Nonetheless, this attack is more visible and requires a persistent connection to the network during an extended period of time in order to achieve an effective attack.. Attack effects: perpetual Alert Mode or forced shutdown Since Hue is an API based platform, requests can be automated with a scripting language 32.

(40) Figure 3.2: Fetching all the data associated with a Philips Hue Bridge like Python. A library like requests lets the attacker perform actions on a loop after retrieving the needed information. A short example can be the following code: import json, requests, time url = ’http://192.168.1.10/api/ → fLuJSBZbU5ioD5VxQgbbwvawdghLP5oui3POXOrj/lights/2/state’. 33.

(41) payload = {’alert’: ’lselect’} headers = {’content-type’: ’application/json’}. while True: r = requests.put(url, data=json.dumps(payload), headers= → headers) time.sleep(2) This enables the alert mode for the Hue lights on a perpetual basis, and overrides any attempt of performing any other action since the time frame for a new request is only 2 seconds. If the time frame is lower, the blinking is not noticeable. Alternatively, one can modify the payload field in order to perform any other kind of denial of service, such as a perpetual off (sending an endless loop of requests to turn off the light). In that case, the request are desirable for the attacker to be as quick as possible to gain effectiveness on the overriding of legit requests.. Attack effects: reconfiguration of the platform The attacker opens a web browser and goes to http://192.168.1.10/debug/clip.html . A REST client will appear. 1. Change IP configuration (Address, DHCP, netmask and gateway) PUT /api/<hash>/config Payload { "ipaddress":"x.x.x.x", "dhcp":true/false, "netmask": "x.x.x.x", "gateway": "x.x.x.x" } 2. Modification and deletion of internal rules and scheme configurations DELETE /api/<hash>/rules/<number> DELETE /api/<hash>/rules/<number> DELETE /api/<hash>/schemes/<number> PUT /api/<hash>/rules/<number> PUT /api/<hash>/schemes/<number> Payload body will differ, but will be typically a JSON request with an ”attribute”:”value” pair. 34.

(42) 3. Switch lights on PUT/api/<hash>/lights/<number>/state Payload { "on": true }. Final Considerations When a bridge authorizes an app or a user, it remains whitelisted until the next factory reset. DELETE actions on the correct URI are not able to remove authorizations. This means, if for some reason an attacker is able to get a valid hash, the access will be permanent. This vulnerability can be combined with the fact that some Hue bridges are over public IPs - and if those two conditions are met, it will mean that an attacker can control the system from the Internet as long as the Bridge is online and factory reset is not performed. Regarding Android monitoring, there are some apps (like Packet Capture) available on Play Store that don’t require a rooted device. They will only sniff traffic in non-promiscuous mode. But if for some reason, an attacker has an authenticated application running on its phone, it will be possible to sniff traffic in clear text and get the hash. One of the possible commands an attacker can run is to change the network configuration (IP, netmask, gateway...). If the Bridge’s network has WAN access, it may be possible to set up a public IP configuration and take control of the Bridge through the Internet. A possible case of study can be trying to make the same attack on the outside of the network, by using a WNIC in monitor mode. In case this is achievable, the attack will be expanded to outside the network.. 3.2. Surveillance: Foscam C1 IP Camera Case. For a demonstration on how surveillance systems can be compromised without a correct monitoring and usage of the network, our lab counts with a Foscam C1 IP Camera 2 . This device supports two streaming protocols: Kerberos and RTSP. While Kerberos is a solid protocol to steam in terms of security, RTSP is highly compromised due to credential sharing with no authentication. 2. Foscam C1 Datasheet available at foscam.us/media/mconnect uploadfiles/c/1/c1%20user%20manual.pdf. 35.

(43) Figure 3.3: Foscam C1. 3.3. Security of the system. The following subsections explain which are the vulnerabilities found for the RTSP[19] video streaming protocol regarding authentication for Basic and Digest authorization modes.. 3.3.1. RTSP Authentication Vulnerabilities. RTSP does not support encription for packets. This means, the contents of any RTSP packets can be disclosed with a direct sniffing (for example, using Wireshark). RTSP protects its services by using authorization, but this can be leaked after accesing to the contents of a RTSP packet. The two modes of authorization in RTSP are: • Basic. This mode is used for a simple, non-costly way of authentication for a client against a server. Usually it is used in environments with UsernamePassword logins (such as IP cameras). For this reason, username and password must be shared through an URL, such as a web application that builds the rtsp://... request; or even raw, for example, a VLC Player client where the user types rtsp://username:password@ipaddress/resource. Then, the URL data is encoded in Base64 and the setup communication begins. • Digest. This mode is significantly more resilient. Credential sharing is protected by hashing public and private data from the camera using MD5 functions. Basic Authorization Mode In Basic Authorization mode, every request from the RTSP stream contains the authorization details encoded in Base64. For example, the credentials admin:admin will generate the token YWRtaW46YWRtaW4= . Figure 3.4 shows 36.

(44) a TCP stream with a disclosed Authorization Token By copying the token string and decoding it (using any online Base64 encoder/decoder), credentials will be disclosed, as shown in Figure 3.5.. Figure 3.4: Packet Sniffing of RTSP Traffic. 37.

(45) Figure 3.5: Credential Disclosure on RTSP Basic Authorization Digest Authorization Mode Digest Mode offers better protection against eavesdropping, and sharing credentials does not compromise them as simple as in Basic Authorization Mode. This is how the Authorization token is generated: HA1 = md5("user:realm:password") HA2 = md5("METHOD:URI") RESPONSE = md5(HA1+":"+nonce+":"+HA2) Being user the login username, realm an information field that can contain the space where the device is deployed (for example ”Streaming Server”), password is self-defining, METHOD as the RTSP method (DESCRIBE, PLAY, ANNOUNCE...), URI the location of the resource and nonce a ”number used once” at random. All this information but the password field is disclosed on sniffing:. 38.

(46) • Username is disclosed in the sniffed packet without encoding, in a field called username=”user”. Security regarding, usernames are available just by sniffing a packet. • Realm is also disclosed as plaintext, in a field called realm=”realm”. • Method is disclosed when decoding the packet as RTSP in your sniffer program. For example, Wireshark is able to parse the packet and detect the method. • URI is disclosed in plaintext as uri=”rtsp://my/uri/ipaddress:8554/resource”. Notice that it also discloses the socket (IP Address + Port), and the name of the resource aiming at. • Nonce is also disclosed in plaintext as a character string. • The final response (this means, the final token hashing HA1, the nonce, HA2 and separators ”:”) is also public. It is remarkable that the safest mode of RTSP authentication provides the attacker with all of this information just by doing nothing more than sniffing a packet. Cracking the password in Digest Mode was not the goal of the research. Several cryptoanalysis and attack vectors against MD5 have been tested, labeling it as a ”poorly secure hash function” cryptographically speaking[20]. Nonetheless, only HA1 has secrecy since we can reconstruct HA2 based on what the packet discloses, and even the full response hash is also provided. This information is valuable and may simplify the task of an attacker searching for a collision.. 39.

(47) Chapter 4. A Solution for BA Protocol Monitoring After the analysis on possible threats and breach points, a defensive approach shall be considered. One possible option may be active solutions : elements that interact and modify the traffic in order to protect the network. While resilience against attacks improve and the required supervision is reduced, some customers may not approve the disadvantages of an active solution, such as: • Lack of control on messages generated by the security tool • Interference with the overall performance of the network • Interruptions and unavailability In order to mitigate these disadvantages and present a flexible yet powerful monitoring system, passive solutions can be deployed. They characterize for not being intrusive, performing listening operations and learning from traffic instead of interacting with the active nodes of the network. SilentDefense complies to the definition of a passive solution for network monitoring. It offers a wide compatibility with several protocols and a highly customizable environment to suit several types of installations. On the following sections, an analysis of a typical architecture will be offered, with a more technical and detailed explanation on each one of the components used for detection and monitoring. Finally, an example of a detection algorithm is presented.. 4.1. Architecture High Level. For a correct understanding of SilentDefense behaviour, an example of a BAS network has been depicted in Figure 4.1. The line in blue represents the Management Layer, where communications are transported over an Ethernet layer. 40.