Tu sei qui:

Internet of Things (IoT) Cybersecurity

Cybersecurity Testing Approach to uncover vulnerabilities

Internet of Thins (IoT) Cybersecurity pertains to the examination of IoT devices and applications for security vulnerabilities, aiming to identify potential threats and security flaws that could jeopardize the system’s integrity and grant unauthorized individuals or systems access to sensitive data stored within these devices.

Given the substantial increase in the use of IoT devices in various sectors, such devices assume a crucial role in the overall data exchange process, managing sensitive information and data. As a result, it becomes imperative for these devices to undergo comprehensive security assessments, even when they undergo software upgrades.

These assessments aid developers in addressing security vulnerabilities within IoT devices and applications, ensuring that they are protected against any unauthorized or unauthenticated actions that may have detrimental effects on the organization.

Regular security evaluations of this nature serve to safeguard both the hardware and software applications from unauthorized access, thereby mitigating potential harm to the organization’s reputation and resources.

Logirobotix has developed a comprehensive multi-tier Internet of Things (IoT) Cybersecurity Testing Approach to uncover vulnerabilities in all layers and ensure the IoT Systems are compliant with security standards.

  • Physical security assessment to identify potential rogue devices, unauthorized access points, or tampering.
  • Hardware security testing to evaluate the integrity and security of the IoT device’s physical components.
  • Peripheral port evaluation to detect potential data leaks from Ethernet, USB ports, LTE, and other interfaces.
  • Application security testing to identify vulnerabilities at the application level and potential logical flaws.
  • Configuration review to identify issues related to access management and encryption within the IoT device.
  • Network vulnerability assessment for various transaction and communication operations.

The objective of Internet of Thins (IoT) Devices Security Test is to assess the effectiveness and adequacy of the IoT device from both a black-box and white-box perspective. Logirobotix will evaluate the following areas:

  • Physical Security
  • Hardware Security
  • Middleware / Frameworks Security
  • Backend Communications Security
  • Peripherals Security
  • Operating System Security
  • Application Security (Analysis of installed components)


The following describes the phase of testing typically conducted during an Interner of Things (IoT) cybersecurity assessment.

Security Architecture Review

Documentation is reviewed and discussions are held with key system engineers to construct a high-level security overview of the system and to identify areas of specific interest or concern. Current security strategy is reviewed, including existing anti-tampering features, digital rights management (DRM), secure boot and “chain of trust” procedures, and related concepts.

Information Gathering

A detailed listing of all major onboard components and their interfaces is created, through a combination of physical inspection of the PCB(s) and review of available technical documentation. Datasheets are obtained for all major components, and communications protocols such as SPI and I2C used by each component are identified for later investigation. Potential debug or maintenance interfaces and/or test points are identified, such as JTAG, UART, or similar vendor-specific interfaces.

Logirobotix specializes in Internet of Things (IoT) Cybersecurity, ensuring robust protection.

Passive Analysis

On-board and external data buses are monitored during normal system use, typically using a specialized device known as a logic analyzer. This is done to determine whether or not information such as encryption keys or other sensitive data are transmitted between components insecurely. Power usage and timing information is captured during cryptographic and other security-critical operations in an attempt to extract sensitive information via so-called “side-channel” attacks.

Active Analysis

Connections are made to identified debug interfaces to uncover any insecure functionality that may be exposed. Non-volatile storage components such as EEPROMs are de-soldered from the PCB, and their contents are extracted for further analysis. Potentially malicious data is injected into identified data buses in an attempt to bypass security controls via unauthorized or unexpected input. If possible, DMA-style attacks are performed using specialized hardware to gain read/write access to the physical memory of the running system.

Some of the checks the security team will be looking for:

Protection against physical attacks:

  • Detection and protection against physical tampering.
  • Detection and protection against unauthorized access.
  • Detection against device tampering.
  • Implementing security measures to prevent unauthorized observation.
  • Implementing surveillance features to capture events and potential threats.
  • Protection against environmental hazards.
  • Safeguarding against unauthorized access to device components.
  • Protection of power and network connections.
  • Disabling unused ports and interfaces.
  • Securing the physical placement of IoT devices to prevent theft or tampering.
  • Implementation of surveillance systems and security personnel presence.

Internet of Things (IoT)

IoT technology has revolutionized various industries, including healthcare, agriculture, transportation, manufacturing, and smart homes. In healthcare, IoT devices can monitor patients remotely, collect vital signs, and transmit data to healthcare providers in real-time, facilitating timely interventions and improving patient outcomes. In agriculture, IoT sensors can monitor soil moisture levels, temperature, and humidity, enabling farmers to optimize irrigation and crop management practices.

Moreover, IoT devices play a crucial role in creating smart cities by optimizing energy usage, managing traffic flow, and enhancing public safety through the deployment of intelligent surveillance systems and emergency response mechanisms.

Despite its numerous benefits, IoT technology also poses significant challenges, including data privacy and security concerns, interoperability issues among devices from different manufacturers, and the potential for system failures or cyberattacks.

As IoT continues to evolve, it holds the promise of further enhancing efficiency, productivity, and convenience across various domains while also prompting discussions about the ethical and societal implications of ubiquitous connectivity and data collection.

Protection against logical attacks:

  • Protection against unauthorized access by implementing strong authentication and access controls.
  • Protection against unauthorized data access.
  • Operating system hardening and keeping it up to date.
  • Whitelisting authorized applications, services, and processes.
  • Running IoT devices with the principle of least privilege.
  • Implementing file integrity checks.
  • Securing event logs and data generated by the IoT device.
  • Using secure communication channels for data transmission.
  • Configuring security best practices for IoT device applications.
  • Implementing antivirus protection for IoT devices.
  • Segregating IoT device networks from other networks.
  • Protection against malware and other cyber threats specific to IoT device

Services Overview

penetration test

Firmware Testing

Embedded firmware penetration testing, as part of the IoT security assessment, primarily focuses on the IoT device’s firmware. This approach encompasses dynamic testing, which is conducted while the firmware is actively running, and static analysis, where the source code can be accessed (e.g., through reverse engineering) to facilitate the identification of vulnerabilities and security issues.

This approach diverges from traditional application security testing, where the primary concern often stems from various internet-based threats. Firmware penetration testing methodology also places emphasis on client-side security, the integrity of the file system, hardware security, and network security. It has long been recognized that the end-user has a significant degree of control over the IoT device.

The firmware testing methodology draws from the OWASP IoT security project, encompassing all aspects of the OWASP IoT Top 10 for 2018, while also incorporating insights and testing techniques from other security testing domains.

As part of Firmware Penetration Testing, the following assessments are performed for the in-scope IoT devices:

  • Get the firmware from various sources.

  • Check the vendor’s website and support forums for firmware updates.

  • Consider sniffing the package during OTA (Over-The-Air) updates.

  • Engage in reverse engineering to examine the firmware.

  • Explore the possibility of duplicating it directly from the device.

  • Determine if the firmware is encrypted.

  • Identify encryption patterns and apply appropriate decryption techniques.

  • If it’s not encrypted, use tools like binwalk to extract the file system.

  • Analyze configuration files and search for hardcoded sensitive values and certificates.

  • Disassemble individual binaries using tools like Hopper, Binary Ninja, or IDA Pro.

  • Look for strings, functions, and cross-references to system() calls.

  • Emulate individual binaries using qemu for further analysis.

  • Investigate the firmware for potential overflow-based vulnerabilities.

  • Consider modifying the firmware, adding backdoors, or creating bindshells.

  • If applicable, attempt to bypass signature verification mechanisms.

Services Testing

In this phase of service testing, the primary focus is on understanding the purpose and functionality of the target applications. This knowledge forms the foundation for appropriately scoping and assessing the service, enabling a clear understanding of the effort and time required for a comprehensive evaluation.


  • Assess the update process for the service.

  • Attempt to find the encryption key and explore the possibility of dumping flash contents from the hardware.

  • Reverse engineer the API communication.

  • Investigate the types of data stored on the mobile device.

  • Look for methods to bypass any kiosk mode that may be in place.

  • Test for vulnerabilities related to connecting USB drives and USB keyboards.


  • Search for Insecure Direct Object References (IDORs) within the service.

  • Check for weak permission level vulnerabilities (e.g., admin, user, superadmin) within the service.

  • Treat it as a regular web service and look for common web vulnerabilities.


  • Utilize Nmap to identify services running on the network as part of the service testing.

  • Pay special attention to outdated services and the presence of default credentials within the service.

  • Employ Wireshark to analyze network traffic related to the service.

Thick Clients:

  • Assess for command injection and overflow vulnerabilities within the service.

  • Reverse engineer the APIs used by the thick client as part of the service testing.

  • Exploit trust components in the thick client application within the service.

Radio Testing

In the realm of radio security testing, it is imperative to adopt a systematic and comprehensive approach to ascertain the vulnerabilities and assess the security of diverse radio protocols. Within this framework, we engage in the evaluation of Raw Radio, BLE (Bluetooth Low Energy), and ZigBee services. The endeavor commences with a meticulous comprehension of the roles and functionalities inherent to each protocol. Subsequently, we undertake the acquisition and scrutiny of data, enabling us to pinpoint potential security concerns and weaknesses. In the ensuing sections, we shall expound upon the specific procedures entailed in the rigorous scrutiny of the security aspects pertaining to these radio services.


  • In this phase of radio service testing, the first step is to work with Raw Radio data.

  • Utilize HackRF or RTL-SDR to identify the frequency being used.

  • Capture the data for further analysis.

BLE (Bluetooth Low Energy):

  • Begin by using a BLE Dongle to identify characteristics and services of the target device.

  • Capture BLE traffic, leveraging tools such as Ubertooth One.

  • Explore the possibility of conducting Relay-based attacks.

  • Employ Gatttool to write data to the target device’s BLE Characteristics.

  • Capture the initial pairing packets and, if encrypted, use tools like crackle to decrypt the traffic.


  • Initiate the ZigBee service testing by finding the ZigBee channel in use.

  • Capture communication data using zb_dump and import it into Wireshark for analysis.

  • Explore the potential for replay-based attacks using zb_replay.

  • Identify encryption keys within the captured communication.

In each of these service testing phases, a systematic approach is crucial, starting with data capture and analysis to understand the characteristics and vulnerabilities of the respective radio protocols.


In the domain of ATM/CDM/IDM/Kiosk security testing, a methodical and rigorous approach is essential to unveil vulnerabilities and assess the security integrity of these critical systems. This comprehensive evaluation encompasses Recon, Physical assessment, OS examination, Application analysis, and Network scrutiny. By adhering to this structured approach, we aim to uncover potential weaknesses that could compromise the integrity and confidentiality of these devices and systems. Let’s delve into the specific steps involved in the rigorous assessment of ATM/CDM/IDM/Kiosk security.


  • Begin with reconnaissance to gather pertinent information.

  • Identify the device model and underlying operating system.

Physical Assessment:

  • Evaluate physical security by attempting to lockpick the device.

  • Inspect for exposed cables, routers, and USB ports, testing the use of USB input peripheral devices.

  • Examine other components connected to the machine, particularly those connected via USB, to acquire hardware details and potentially create malicious input devices.

Operating System (OS):

  • Assess the OS security by attempting to escape Kiosk Mode through keyboard shortcuts during the boot process.

  • Investigate the possibility of accessing the Boot Menu.

  • Test bootable USB drives to explore the potential of booting into another OS.

  • Determine if the hard drive is encrypted; if not, modify system files to gain administrative privileges.

Application Analysis:

  • Analyze the application layer to identify sensitive files.

  • Search for unobfuscated DLLs, perform reverse engineering, and attempt to extract keys, tokens, and encryption/decryption methods.

  • Look for common vulnerabilities in Thick Client Applications.

Network Assessment:

  • Employ Wireshark to capture and analyze network traffic during regular user workflows.

  • Examine inbound and outbound restrictions.

  • Identify open services and interact with them.

  • In case of obtaining a shell on the machine, explore interactions with other network assets.

  • Scrutinize sensitive network shares, default credentials, and other services, with the utmost care and authorization.

This systematic approach enables a comprehensive evaluation of ATM/CDM/IDM/Kiosk security, ensuring the identification and mitigation of potential security risks and vulnerabilities within these systems.


Threat Classification and Reporting

When any exploitable vulnerability is discovered, further research is conducted on that vulnerability to identify its level of severity. The risk is calculated according to the following criteria:

  • Impact: The security impact on the web application in the event of an exploitation of this vulnerability by an attacker. This criterion indicates the benefit of the attack to the attacker.

  • Ease of Exploitation: The level of difficulty for an attacker to exploit this problem. Difficulty could increase due to technical complexity, the need for prior knowledge of the network, or other factors. This criterion indicates the cost in time and resources of the attack for the attacker.

  • Popularity and Ease of Identification of the Vulnerability: This criterion factors in the public availability of information and tools to detect the vulnerability. Problems that have easy to use exploit code available on the Internet, for example, would get a higher rating. This criterion indicates the probability of an attack.

The risk is classified as follows:

Risk Classification


Critical Risk

Vulnerabilities in this category usually have the following characteristics:

  • Exploitation of the vulnerability results in root/administrator-level access to the system;

  • The information required in order to exploit the vulnerability, such as example code, is widely available to attackers;

  • Exploitation is usually straightforward, in the sense that the attacker does not need any special authentication credentials or knowledge about individual victim systems, and does not need to persuade a target user, for example via social engineering, into performing any special functions.

High Risk

Vulnerabilities that score in the high range usually have the following characteristics:

  • The vulnerability is difficult to exploit;

  • Exploitation does not result in elevated privileges, but may grant unintended access to data;

  • Exploitation does not result in a significant data loss.

Medium Risk

Vulnerabilities that score in the medium range usually have the following characteristics:

  • Denial of service vulnerabilities that are difficult to set up;

  • Exploits that require an attacker to reside on the same local network as the victim;

  • Vulnerabilities that affect only nonstandard configurations or obscure applications;

  • Vulnerabilities that require the attacker to manipulate individual victims via social engineering tactics;

  • Vulnerabilities where exploitation provides only very limited access.

Low Risk

Vulnerabilities in the low range typically have very little impact on an organization’s business. Exploitation of such vulnerabilities usually requires local or physical system access.


These are not vulnerabilities, but additional information gleaned from the target during vulnerability testing.

After identification and classification of the findings is complete, the details of each finding will be documented and detailed recommendations will be given on how to mitigate the discovered threats. Navigate the future with our cutting-edge Internet of Things solutions, seamlessly integrating technology into your life. Discover the future of smart textiles with our innovative integration of the Internet of Things in textile fabric. Our cutting-edge technology enhances fabrics with sensors and connectivity, offering unparalleled functionality. Experience intelligent, responsive materials that adapt to your needs, transforming everyday textiles into interactive, high-tech solutions for a smarter lifestyle.

Risk Calculation

Logirobotix utilizes the Basic Common Vulnerability Scoring system (“CVSS”) version 3 by default for Residual Risk calculation, which takes into consideration the following criteria:

  • Attack Vector: this metric indicates how ‘close’ an attacker needs to be to the object. Is physical access needed at one end (AV:P)? Or can the object at the other end be attacked via the network?

  • Attack Complexity: how easily can the attacker reach their target? Is it within their control?

  • Required Privileges: does the attacker need privileges (authorization) before they can carry out their attack? If this is the case, the score is lower, otherwise, it is higher.

  • User Interaction: must a user do anything first before the attacker reaches their target? If the user, for example, has to click on a link first, the value would be ‘required’ (UI:R).

  • Scope: the scope describes whether the effects of an attack ‘only’ affect the vulnerable components or other components. In the last case (‘changed’ S:C), the scope score increases the base score if the latter has not already reached the maximum value of 10.

  • Confidentiality Impact: this metric indicates to what extent the attack affects confidentiality. A ‘high’ (C:H) value means that confidentiality has been totally lost.

  • Integrity Impact: in the same way, this metric describes the influence on the integrity of the data. If, for example, the attackers were able to modify all files, the impact would be set to ‘high’ (I:H).

  • Availability Impact: this measure is also very similar to the other impact metrics. If the attacker succeeds or is able to succeed in denying the availability of the components so that they can no longer be accessed, the maximum value ‘high’ (A:H) would be reached