The Internet of Things has changed the way we interact with the environment around us in our daily life, and it is increasingly common to find more than one IoT device in our home. However, the current design approaches adopted by the vendors are more oriented towards customer usability than to security. This often results in more and more devices exposing serious security problems. This work focuses on the security implications, i.e. the threats and the risks, of the current IoT pairing mechanisms and represents a step forward in the definition of our automated penetration testing methodology. In addition to the general threat model for a general IoT pairing process, we present the analysis of a QR code-based pairing mechanism implemented by a class of devices taken from the real market, which led to the identification of two vulnerabilities, one of which publicly disclosed as CVE-2021-27941.
Internet of Things is becoming an accepted reality. Vocal assistants, smart lamps, smart plugs are more and more common in our houses. Industrial systems include smart meters, connected robots, and drones. The health system makes large use of portable devices for continuous monitoring of critical sick persons. Cars are complex and connected computer systems. As a matter of facts, our daily life is full of interactions with several multiple surrounding devices.
Users need to continuously interact with new devices, establishing a connection and correctly
using them. Pairing is the term adopted for describing the process of establishing a connection
with a new device [
However, pairing includes complex procedures and relies on the authentication of the peers
connecting each other. As commonly happens, there is a clear trade-of between usability of
pairing processes and the security, of the process itself [
To assess the security of IoT systems, our research team is working on a methodology that
aims at automating IoT-based security testing. This paper, together with [
In this paper, we focus on the pairing process of IoT devices and made a systematic analysis of smart devices for home systems, building a general-purpose threat model. Thanks to our methodologies, we made a threat-based analysis of the devices pairing process, identifying the possible attacks that implement the identified threats, demonstrating their feasibility on real devices, and how some pairing systems may lead to dangerous side efects. The experiments lead to the discovery of two vulnerabilities, for one of which we requested a CVE id. Also, we contacted the vendor before the submission of this paper to leave him the time to apply some internal countermeasures to mitigate the vulnerabilities.
As a summary, the main contributions of this work are: (i) a generic Threat Model for the IoT device pairing process, (ii) a demonstration of the usefulness of our threat-based penetration testing approach, (iii) a detailed security analysis of a particular pairing scheme from the real market, (iv) the discovery of two vulnerabilities in real-world class of devices.
The remainder of the paper is organized as follows: Section 2 illustrates the state of art, focusing on the existing pairing schemes and the security analysis available in the literature on the topic. Section 3 briefly summarizes our threat-based approach to penetration testing and the Threat Model we made for the IoT pairing process. Section 4 describes the analysis on a real-world class of devices and presents one of the two discovered vulnerabilities. Section 5 summarizes the conclusions and the future works.
In the current literature, the term pairing is defined as the bootstrap process that creates a
communication channel between two entity, which have never met each other before [
El-Hajj et Al. [
Similarly, Meneghello et Al. [
Ferrag et al. [
(a) Generic Pairing Schema (b) Case Study Pairing Schema
As concerning the device pairing process, and in particular, the process of pairing a device
to the customer’s WiFi network, very few papers are available in the literature. A survey
on the available IoT pairing schemes is available in [
Due to the intrinsic characteristics of the wireless communication links, those pairing procedures are often vulnerable to Man-In-The-Middle (MITM) attacks. Therefore, an auxiliary out-of-band channel (OOB) is usually involved for the key-exchange step. The authors outline that this communication channel is not necessarily a dedicated PHY (Physical) channel, but could also be a HCI (Human-Computer Interaction) channel, which is a channel where data is transmitted through human interaction.
As concerning the existing pairing techniques and their underlining technologies, multiple
schemes have been proposed [
Moreover, the existent pairing solutions often rely on dedicated protocols built on-top of
physical channels [
As already outlined, some pairing solutions rely on particular OOB channels to securely
authenticate the devices, i.e. the Human Computer Interaction (HCI) channel. Within an HCI
channel, the user is asked to perform a physical action, like pressing a button or scan a QR code.
Nevertheless, HCI channels are subjected to the human error, so the user could become the
"weakest link" of the entire pairing procedure [
Despite the cited references, currently, there is no standard reference architecture for the pairing mechanism, and on which base a systematic security analysis approach. Accordingly, there is a clear need for a standard security solution and the definition of the general-purpose best practices for IoT-based systems.
In this paper, we focus on a specific pairing schema that uses an OOB channel, an HCI and an external service for the device configuration process. Figure 1b shows the involved parties and summarizes, at the same time, the steps required by the pairing schema.
This particular schema involves an initial HCI interaction (step 1), by which the user starts the pairing process on both the IoT device and his user equipment (UE), usually a smartphone. The HCI step could also involve the acquisition of a device secret, later used to authenticate the communication. The user equipment retrieves some device information from a remote service (step 2) and shares the network credentials to the IoT device (step 3), possibly throughout and OOB channel. Next, the device joins the user’s network (step 4) and registers itself to a remote service (step 5), typically to be remotely associated with the customer’s account, thus completing the configuration process.
This work analyzes the threats for this particular pairing schema and represents another
little step forward in the demonstration of the versatility of our general-purpose methodology
for systematic and threat-based penetration testing, already adopted in other contexts [
The methodology adopted in this work was previously proposed in [
According to our approach, the System-under-Test (SuT) is described by the Multi-cloud
Application Composition Model (MACM) formalism [
In MACM, system components are modelled with graph nodes, whereas relationships between system components are represented with directed links between nodes. The proposed formalism allows to properly represent system architecture components and also enable to annotate security-concerning information in a human and machine-readable format.
Thanks to the techniques described in [
In the planning phase, penetration testers analyze the identified threats and select the most
promising one, based on his experience and his competencies in terms of possible attacks.
Currently, we are working on techniques that aim at automating this step (in [
As anticipated, the automated threat modelling procedure relies on a predefined threat catalogue, that collects high-level and system-independent threats, organized by asset type.
In our methodology, a threat is modelled as the triple { ℎ, , ℎ},
representing the possibility of a Threat Agent, i.e. a malicious actor, to cause damage to an Asset,
i.e. something that has a value in the system, through a specific Behavior, i.e. a set of actions
that implies human and/or automated interactions with the target systems [
The Table 1, reported in Appendix, contains an excerpt of our catalogue with the specific
behaviours of the threats for the IoT pairing processes. Our catalogue contains additional
information to characterize the threats (like the STRIDE classification [
Also, we identified and reported in Table 1 two classes of possible threat agents: the Malicious User and the Malicious Service. A Malicious User is a hostile attacker who has internal access to the infrastructure (i.e. connected to the LAN Network) to perform the attacks with no legal and ethical constraints. The threat agent goal is to damage or steal the asset, denying, causing harm or taking control of the asset. The skills required by the attacker(s) is operational, or rather someone who understands the technology background, but is not an expert in performing the attack methods. Unlike the Malicious User, a Malicious Service can also have external access to the system and aims to steal sensitive data. To carry out a social engineering attack, the threat agent requires minimum skills, but he must register a domain that exposes the attacker to greater legal limits.
As an example of identified threats, threat T2 of Table 1 consider the case in which a malicious user could compromise the IoT Device by replacing it with a malicious one or by connecting a malicious User Equipment to the customer’s device without the legitimate users’ awareness. This would afect the IoT device integrity.
Other threats target the customer’s network: a malicious user could, for example, connect a malicious IoT device to the user’s WiFi network, or physically disturb the communication link to prevent the pairing process from completing (e.g. Jamming). Also, an attacker could manage to compromise the communication between the UE and the remote service. Further, the latter could be subjected to Denial of Service, an attack that aims at denying the service availability. Or worse, it could be subjected to spoofing, i.e. an attacker could replace a legitimate service with a malicious one and obtain sensitive information.
Based on the threats described in this section, the penetration tester analyzes the threat list and constructs the specific attacks in the Planning phase.
In this section, we present the methodology applied for the security analysis of a real-market case study, about a pairing schema matching the one presented in Figure 1b. In particular, we analyze the implementation details and the weaknesses exposed by a particular QR-code based pairing schema, tied to the eWeLink hub platform.
eWeLink [
The application, depending on the device class, provides five diferent methods for pairing:
(i) the Quick Pairing mode, a pairing mechanism based on the ESP-Touch protocol (which
we already found vulnerable [
Among the devices supporting the latter pairing schema, we tested the ITEAD Sonof Micro [22], depicted in Figure 3a, which is a USB smart adapter that converts an ordinary USB power port to a smart controlled switch. It permits to schedule stop charging times, check the power-on status, or remotely turn on/of the attached devices.
The steps required to pair a supported device are reported in Figure 3b. The process starts by setting the IoT device into pairing mode (step 1), and by selecting a new device association on the eWeLink application, tapping on the QR code pairing mode (step 2 and 3). The user is asked to scan the QR code label shipped with the device (step 4) and, then, to insert his WiFi network credentials (step 5). Finally, the device joins the user’s WiFi network and gets associated with the user’s account (step 6).
Note that, the steps form 1 to 5 in Figure 3b directly coincide to the first step of the generic (a) Sonof Micro
(b) QR code pairing through the eWeLink application pairing model introduced in Figure 1b, i.e. the user-device HCI interaction, described in Section 2. Conversely, step 6 in Figure 3b encloses all the remaining steps (from 2 to 5) of the pairing model of Figure 1b. This is because that the low-level device pairing operations do not require any human intervention, and are automatically executed once all the initial protocols parameters are set by the customer.
To start the security evaluation, and according to the first step of our methodology, we devised the MACM model of the entities involved in the pairing process. The graph in Figure 4 represents these assets, grouped by type in diferent colours, and their relationships. Among the green coloured network nodes, note the softAP network raised by the IoT device for its configuration. Also, note the remote service node, hosted by the Cloud Service Provider (CSP), that is used by both the smartphone (and the eWeLink mobile app) and the IoT device for the configuration. Finally, the IoT Gateway node represents the user’s target WiFi AP.
According to the above-described approach, we derive the detailed threat model of the system from the MACM. For brevity reasons we do not report here the model, but we will refer to the threats using the information in the catalogue reported in the Appendix, in Table 1. For each threat in the threat model, a certain number of security test plans were produced and then executed by the penetration tester (steps 3 and 4 of the methodology), looking for possible security issues. Hereafter, we report only the successful tests, i.e. the ones that led to a successful attack.
For each threat in the threat model, a certain number of security test plans were produced and then executed by the penetration tester (steps 3 and 4 of the methodology), looking for possible security issues. Hereafter, we report only the successful tests, i.e. the ones that led to a successful attack.
In our case, the device_id was a 10 characters long alphanumerical string representing a unique device id. After the QR code scan, the companion application extracts the SSID name and, based on the device id parameter, queries a remote service to retrieve a secret key and other device information (e.g. device model and device type). During the penetration testing steps, we found that, by having a valid platform account, it is possible to manually query the Cloud APIs and retrieve the secret key of any device just by knowing its device id, whether already associated with a network or not.
Later, the mobile application asks the user to insert both the target WiFi network SSID and passkey and finally connects the smartphone to the device WiFi AP network (unprotected by default) to perform the configuration. Accordingly, applying the attacks for the threat T4 in Table 1, we intercepted the HTTP post configuration request to the device. The intercepted JSON message contained the target WiFi network authentication details and the Cloud API endpoint for the user reference region location. This JSON message was encrypted with the AES algorithm, using a 0-pad IV and the previously retrieved secret key. The IoT device has a hard-coded copy of the secret key and, thus, can decrypt the incoming messages.
According to our test plan results, an attacker could leverage this specific pairing pattern to gain full access to the client’s WiFi network. In fact, the device softAP SSID also contains the device id information and, by looking at this field, a malicious attacker would be able to retrieve the related device private key. By knowing this encryption key and due to the openness of the device WiFi softAP, an attacker can snif the HTTP configuration message sent by the mobile user equipment and decrypt the user’s WiFi network credentials.
Hereafter, an example of decrypted JSON {“ssid" : “Test-Network", “password" : “Test-Password", “serverName" : “eu-disp.coolkit.cc", “port" : 443}, where the “Test-Network" and “Test-Password" parameters are the network credentials we chose for our testbed configuration. Also, note the presence of the eu-disp.coolkit.cc endpoint serving the European region.
Once received the pairing parameters, the device stops advertising its WiFi AP, joins the user’s WiFi network and registers itself with the remote API Cloud platform.
Note that, this vulnerability does not expose only the IoT device, but the entire user’s network, even though, for the actual exploitation, the threat agent must be located in the proximity of the pairing device.
The security of the eWeLink QR code protocol and, in particular, the confidentiality of the user’s network credentials, rely on the proper AES encryption of the configuration messages. The problem is that the QR code does not encode any security information related to the IoT device (only the public SSID is encoded into the QR label). Instead, a publicly accessible API endpoint is called to retrieve the device secret key, which is used to implement the AES security layer of the pairing protocol. This makes the HCI interaction via QR code useless from a security point of view. Currently, there isn’t much users can do to prevent their network credentials from being exposed during a pairing session based on the eWeLink QR code schema. Monitoring the API endpoint for secret key retrieval, or any attempt to associate a secret key exclusively to its first calling user would be inefective solutions, and a possible cause of denial of service to the customers, intended as the inability to complete a legitimate pairing process. One solution would be to encode the secret key inside the QR label. However, problems arise if the QR sticker is lost: it would become impossible to re-pair the device.
We responsible disclosed the vulnerabilities we found to eWeLink, which acknowledged back and defined a set of provisional countermeasures before a complete API re-design.
We reserved a CVE ID number and published the vulnerability as CVE-2021-27941 [23, 24]. 5. Conclusions “Security is the dark side of Internet of Things"1 emphasizes that the IoT is a young technology and, as a consequence, it sufers from many concrete issues that must be addressed as soon as possible. This paper is part of a research line that aims at defining a fully automated and threat-based technique for the security assessment of IoT systems. Moreover, our analysis led to the production of a general-purpose threat model for the IoT pairing processes, that can be used for further analysis and can be integrated with our automated risk analysis process. We hope that this contribution raises the awareness of the existing security issues in home-based systems. The security analysis enabled us to disclose and report two major vulnerabilities to the vendor. We also registered a CVE number for one of them: CVE-2021-27941. We didn’t disclose any detail about the second vulnerability, which has a major severity, to give eWeLink enough time to implement a correction. We are working on extending the approach to support other pairing schemes and testing more devices, and on the automation, as much as possible, of the entire process. Moreover, as anticipated, we are integrating the testing process with our risk analysis methodologies, to ofer a clear definition of the level of risk associated with the adoption of new devices.
cc/en/. [19] Apple, Apple HomeKit, last access, 2021. URL: https://www.apple.com/shop/accessories/ all/homekit. [20] Google, Google Nest, last access, 2021. URL: https://store.google.com/category/connected_ home. [21] Amazon, Amazon Echo, last access, 2021. URL: https://www.amazon.it/l/15755810031. [22] ITEAD, Sonof Micro reference, last access, 2021. URL: https://www.itead.cc/ sonof-micro-5v-usb-smart-adaptor.html. [23] CVE-2021-27941, MITRE CVE reference, last access, 2021. URL: https://cve.mitre.org/ cgi-bin/cvename.cgi?name=CVE-2021-27941. [24] CVE-2021-27941, CVE reference, last access, 2021. URL: https://github.com/salgio/ eWeLink-QR-Code.