Internet of Things (IoT) threats present potential risks to connected devices and networks. Find out what threats can arise in the context of IoT and how to prevent them.
1179 
In a world where every gadget is becoming smart and our home is turning into a large network of connected devices, the issue of security is becoming vital. With the rapid growth of the Internet of Things (IoT), a new range of threats is emerging that requires a deep understanding and effective methods of their detection. Welcome to the third part of our article series: “Threats in the Internet of Things”. In this article, we focus on IoT security testing methodology. This chapter will provide you with a systematic knowledge of how to properly approach security testing of IoT devices, taking into account their unique characteristics and potential vulnerabilities. IoT devices are already actively used in various areas of our lives: from simple household devices such as refrigerators and televisions to industrial equipment.
However, their rapid development often outpaces security, leaving users defenseless against cybercriminals. In our part, we will deal in detail with the main threats that can happen in the world of IoT. From software vulnerabilities to physical access to devices. We’ll also cover recommendations for effectively testing and securing your IoT systems. Immerse yourself in this exciting world with us, learn the latest techniques and recommendations, and always be one step ahead of potential attackers. Our goal is to help you become an expert in Internet of Things security.
Where do you start if you want to test your IoT system for vulnerabilities? If the attack surface is small enough, as in the case of a single web portal controlling a security camera, then setting up a security check can be simple. However, when the testing team does not follow the established methodology, it can miss critical points of the application.
This chapter provides a detailed list of steps to follow when testing to overcome protection. To do this, we will divide the IoT attack surface into logical layers, as shown in Fig. 3.1.
When testing IoT systems, you need a robust evaluation methodology like this, as IoT systems are often made up of many interacting components. Let’s consider the case where the pacemaker is connected to a home monitoring device. The monitoring device can send patient data to a cloud portal via a 4G connection so doctors can check for abnormalities in the patient.
Medical personnel can also configure the pacemaker with the help of a programmer that uses a near-field wireless communication (NFC) module and a proprietary wireless communication protocol. This system consists of many parts, each with a potentially significant attack surface that a blind, disorganized security assessment is unlikely to successfully identify. To ensure successful testing, we will conduct a passive study and then discuss physical hardware, network, web application, host, mobile application, and cloud testing techniques.
Passive intelligence, also known as open source intelligence (OSINT), is the process of gathering targeted data without direct communication with systems. This is one of the initial steps in any assessment; It should always be performed to get an idea of the general state of affairs. For example, you can download and study device manuals and chipset specifications, Browse online forums and social networks, or ask leading questions to users and technical staff. It is also possible to collect internal hostnames from TLS certificates issued as a result of certificate transparency, a standard that requires trusted certificate authorities to record all information about issued certificates in public logs, which makes it possible to identify mistakenly or maliciously issued certificates.
System manuals can provide a huge amount of information about the inner workings of devices. They can usually be found on the official website of the device manufacturer. If that doesn’t help, try an advanced Google search for PDFs that contain the device name, for example by searching for device and adding inurl:pdf to the query.
It’s amazing how much important information can be found in manuals. Our experience is that they can reveal default usernames and passwords that are often left in a production environment, detailed system and component specifications, network diagrams and architectures, and troubleshooting topics that help identify vulnerabilities.
If you’ve identified specific chipsets installed on the hardware, it’s also worth looking for the corresponding datasheets (electronic component manuals), as they may contain information about the chipset pins used for debugging (for example, the JTAG debug interfaces discussed in Chapter 7).
Another useful resource for devices using radio communication is the online FCC ID database (https://fccid.io/). An FCC ID is a unique identifier assigned to a device registered with the US Federal Communications Commission. All wireless emitting devices sold in the US must have an FCC ID. By searching for a specific device’s FCC ID, you can find detailed information about the device’s wireless operating frequency and power, internal photos of the device, user manuals, and more. The FCC ID is usually engraved on the body of the electronic component or device (Figure 3.2).
Patents can provide information about the inner workings of certain devices. Try searching for the vendor name on https://patents.google.com/ and see what comes up. For example, a keyword search for “medtronic bluetooth” should lead you to a description of the Implantable Medical Device (IMD) protocol published in 2004.
Patents almost always include block diagrams that can help you evaluate the communication channel between the device and other systems. In fig. 3.3 A simple block diagram for the same IMD shows the critical attack vector.
Notice that the arrows go in and out of the IMD column. The remote system action Patient Action & Advice can initiate a connection to the device. As you follow the chain of arrows, note that the action may also update the device program to change settings that may harm the patient. For this reason, a remote system creates risks of remote hacking, either through an unsecured mobile application or through the remote system itself (usually implemented in the cloud).
It’s surprising how much public information can be found on social media, online forums, and chat rooms. You can even use Amazon and eBay reviews as sources of knowledge. Look for users who complain about certain features of the device; Mistakes at work sometimes show vulnerability. For example, you may encounter a user complaint about a device crashing under many conditions. This is a good reason to investigate the situation in more detail, because it could be a logic error or a security vulnerability that causes memory corruption by entering certain data or commands into the device.
In addition, many users also publish detailed product reviews with specifications and images of the devices in disassembled form. Also check LinkedIn and Twitter profiles or posts. Engineers and IT specialists who work for manufacturers of IoT systems can uncover interesting technical ideas. For example, if a person indicates that they have significant experience with a particular processor architecture, it is very likely that many of the manufacturer’s devices are built using that architecture. If another employee describes (or, less often, praises) a particular framework, the company is likely to use it for software development. Generally, every IoT industry has established experts who can be turned to for useful information.
For example, if you were assessing the security of a power plant, surveying operators or technicians about their work processes could be useful in identifying potential attack vectors. In the medical world, the system administrator and primary operator of an IoT system is often a nurse. Therefore, they know the details about the device and you should communicate with them as much as possible.
One of the most important attack vectors in an IoT device is its hardware components. After gaining access to the hardware components of a system, attackers often elevate their user privileges because the system almost always implicitly trusts anyone with physical access. In other words, if an attacker has physical access to your systems, you can assume it’s game over. Let’s assume that the most motivated threat actors (for example, funded by the state with time and practically unlimited resources) have a physical copy of the device at their disposal. Even for specialized systems such as large ultrasound machines, criminals can obtain equipment from online marketplaces, from companies that dispose of the devices hazardously, or even steal them. They don’t even need the exact version of the device.
Vulnerabilities often span multiple system generations. The hardware-level evaluation should include testing of peripheral interfaces, bootable media, physical keys, tamper protection, embedded software, debug ports, and physical durability.
Peripheral interfaces
Peripheral interfaces are physical communication ports that allow you to connect external devices such as keyboards, hard drives, etc., as well as network cards. Check that the USB ports or PC card slots are active and bootable. We gained administrator access to various x86 systems by loading a custom operating system onto the device, mounting an unencrypted file system, extracting compromised hashes or passwords, and installing our software on the file system to override technical security measures. It is also possible to eject hard drives and read or write to them even without access to the bootable USB ports, although this method is less convenient. Please note that unauthorized ejectors may damage components.
The attack can be carried out through USB ports for another reason: some devices, mainly Windows-based, have a kiosk mode in which the user interface has limited capabilities. Consider an ATM for cash withdrawals; even if it is actually running the embedded Windows XP operating system, the user only sees a limited GUI with a small set of commands. Imagine what you could do if you could plug a USB keyboard into an open port on your device. With certain keyboard shortcuts, such as Ctrl+Alt+Delete or the Windows key, you can exit the kiosk mode and access the rest of the system directly.
Boot environment
For systems that use a regular BIOS (typically x86 and x64 platforms), check to see if a BIOS password is set at boot and what your preferred boot order is. If the system first attempts to boot from removable media, you can boot the operating system without making any changes to the BIOS settings. Also, verify that the system enables and prioritizes the Preboot Execution Environment (PXE) before booting, which allows clients to boot the operating system over the network using a combination of DHCP and TFTP. This leaves attackers with the ability to configure download servers from a rogue network. Even if the boot sequence is securely configured and all settings are password-protected, you can generally reset the BIOS to default, clean, and unprotected settings (for example, by temporarily removing the BIOS battery).
If your system has Secure Boot from the Unified Extensible Firmware Interface (UEFI), evaluate its implementation. UEFI Secure Boot is a security standard that verifies that the boot software has not been modified (for example, by jailbreaking). For this, signatures of UEFI firmware and operating system drivers are checked. You may also encounter Trusted Execution Environment (TEE) technologies such as TrustZone on the Arm platform or Qualcomm Technologies’ Secure Boot feature, which helps verify secure boot images.
Castle
Check if the device is protected by any kind of lock, and if so, how easy it is to pick the lock. Also check if there is a universal key for all locks or a separate one for each device. In our evaluations, we’ve seen cases where all devices from the same manufacturer used the same key, rendering the lock useless because anyone in the world could easily obtain a copy of the key. For example, we found that a single key could unlock an entire line of cabinets that provided physical access to the configuration of the infusion pump system.
To evaluate a lock, you’ll need a set of hacking tools – in addition to knowing the type of lock you’re using. For example, a toggle lock opens differently than an electrically operated lock, which may not open or close when the power is turned off.
Prevention and detection of unauthorized access
Make sure the device is protected from unauthorized access. One way to protect it is to use perforated tape labels that indicate the fact of dissection. Other tamper-proof features include tabs, clips, special epoxy-coated covers, or physical fuses that can erase sensitive data if the device is disassembled. Intrusion detection mechanisms send alerts or create log files on the device when they detect an attempt to compromise the integrity of the device. It is especially important to verify security and detect unauthorized access when conducting corporate IoT penetration testing. Many threats come from within – from employees, contractors or former employees – so intrusion protection can help detect any counterfeit devices. It will be difficult for an attacker to dismantle the anti-tamper device.
Microprogram
We will consider firmware security in more detail in Chapter 9, so we will not dwell on this topic here. In the meantime, be aware that accessing the firmware without permission can have legal consequences. This is important to know if you plan to publish a security study in which you have accessed the firmware or refactored the executables found in it. See the IoT Hacking Laws section to find out what actions are legal.
Debugging interfaces
Make sure you have debug interfaces, services, or test points that the manufacturer can use to simplify development, production, and debugging. You’ll usually find these interfaces in embedded devices and can use them to gain root access right away. We wouldn’t have been able to fully understand many of the devices we tested if we hadn’t first rooted the systems by interacting with the debug ports, because there was no way to access and test the current system. At first this may require some familiarity with the inner workings of the communication protocols used by these debug interfaces, but the end result is usually worth it. The most common types of debugging interfaces include UART, JTAG, SPI, and I2C.
Physical stability
Check the limitations related to the physical characteristics of the equipment. For example, let’s evaluate the system for battery drain attacks, which occur when an attacker overloads a device, which leads to battery discharge in a short period of time and subsequent denial of service. Consider how dangerous this is for an implanted pacemaker, on which the patient’s life depends. Another type of test in this category is bug attacks, deliberate hardware failures provoked to overcome security measures during sensitive operations. One of our most successful attacks was booting an embedded system in superuser command-line mode when we performed a PCB crash attack. Also, try secondary channel attacks, such as differential power analysis, where they try to measure the power consumption of a cryptographic operation to obtain secrets.
Studying the physical characteristics of the device will help to draw conclusions about its safety as a whole. For example, a miniature device with a long battery life may have weak forms of encryption of the network communication channel. The reason is that using the computing power required for stronger encryption will drain the battery faster and its capacity is limited by the size of the device.
The network layer, which includes all components that communicate directly or indirectly over standard network communication channels, is usually the largest attack vector. We will divide the process of testing it into several parts: reconnaissance, attacks on the network protocol and services, and wireless protocol testing.
Although many of the other checks discussed in this section affect network performance, we have devoted separate sections to them. For example, the evaluation of web applications, due to its complexity and variety of actions, deserves special attention.
Exploratory
We’ve already discussed the steps you can take to perform passive intelligence on IoT devices in general. In this section, we describe active and passive network reconnaissance, which is one of the first steps in any network attack. Passive reconnaissance may involve listening to a network of payloads, while active reconnaissance (reconnaissance that requires interaction with a target) requires direct interrogation of devices.
Testing on a single IoT device is a relatively simple process as only one IP address needs to be scanned. But in relation to a large ecosystem, such as a smart home or medical system with many devices, network intelligence can be more complex. We will cover host discovery, service version determination, operating system identification, and network topology mapping.
Discovering the host
Host discovery determines which systems are running on the network by checking them using a variety of methods. These methods include sending Internet Control Protocol (ICMP) echo request packets, performing TCP/UDP scans on public ports, listening for broadcast traffic on the network, or generating an ARP request to verify that hosts are on the same L2 segment. (L2 refers to Layer 2 of the OSI computer network model. It is the data link layer that is responsible for transferring data between nodes on the same network segment at the physical layer. Ethernet is a common data transfer protocol.) For complex IoT systems such as servers , which monitor surveillance cameras that cover many different network segments, it is important not to rely on any particular method. Use different combinations to increase your chances of bypassing firewalls or strict virtual local area network (VLAN) configurations.
This step can be most useful in cases where we are performing an IoT penetration test without knowing the IP addresses of the systems under test.
To determine the service version
After defining the active servers, define all listening services. Start by scanning TCP and UDP ports. Then do a combination of banner capture (connecting to the network service and reading the results it returns) and probing with fingerprinting tools like Amap or the -sV options in Nmap. Remember that some services, especially medical devices, are prone to errors even with simple testing. We’ve seen IoT systems crash and simply reboot after analyzing them with Nmap’s versioning feature. This scanner sends packets specially designed to receive responses from certain types of services without sending any information when connecting to them. Obviously, these kinds of packets can cause some sensitive devices to become unstable, as these devices do not have a reliable input signal to access their network services, leading to memory corruption and other issues. Try again later.
Identification of the operating system
You will need to determine the exact operating system running on each of the hosts under test so that you can develop exploits for them later. At least specify the architecture (eg x86, x64 or ARM). Ideally, you should determine the exact OS update level (for Windows) and kernel version (for Linux or Unix-based systems in general).
You can determine an operating system over a network by analyzing a host’s responses to specially crafted TCP, UDP, and ICMP packets, a process called fingerprinting. These answers will vary slightly in the implementation of the TCP/IP network stack in different operating systems. For example, some older Windows systems respond to a FIN probe packet with an open port with a FIN/ACK packet; others respond to RST, And still others do not respond at all. By studying the statistics of these responses, you can create a profile for each version of the operating system, and then use those profiles to identify them. (For more information, see TCIP/IP Fingerprinting Methods Supported by Nmap in the Nmap documentation.)
Service scanning can also help with operating system fingerprinting, as many services provide system information in their banner ads. Nmap is an excellent tool for both tasks. But be aware that operating system fingerprinting of some sensitive IoT devices can cause crashes.
Compilation of a topological map of the network
A topology map models the connections between different systems in a network. This step is used when you need to test an entire ecosystem of devices and systems, some of which may be connected through routers and firewalls, and not necessarily at a single L3 site. (L3 refers to layer 3 of the OSI computer networking model. This is the network layer; it is responsible for transmitting and routing packets. Layer 3 comes into play when data is transmitted through routers.) Creating a network map of verified assets becomes useful for threat modeling: it lets you see how an attack that exploits a chain of vulnerabilities across multiple servers can compromise assets.How important is the product? In a tuxedo. Figure 3.4 shows a high-level topology diagram.
This abstract network map shows a patient with an implanted medical device communicating with a home monitoring device. The home device, in turn, uses a local Wi-Fi connection to send diagnostic data to the cloud, where the doctor periodically monitors it to detect abnormalities.
Attacks on network protocols and services consist of the following stages: vulnerability scanning, network traffic analysis, reverse engineering and operation of the protocol or service. You can also perform the vulnerability scan independently of the other steps, otherwise you need to perform the steps sequentially.
Vulnerability scanning
Start by checking databases such as the National Vulnerability Database (NVD) or VulnDB for known vulnerabilities in open network services. Sometimes the system is so outdated that the report of the automatic vulnerability detection tool is several pages long. You can even exploit some vulnerabilities remotely without authentication. Run at least one scanning tool to quickly identify existing vulnerabilities. If you discover a serious vulnerability, such as remote code execution, you may be able to gain access to a command-line shell on the device. Always monitor the scanning environment and watch closely for unexpected downtime.
Analysis of network traffic
At the beginning of the security assessment process, use a traffic capture tool such as Wireshark or tcpdump to run for a while to give you an idea of the communication protocols being used. If an IoT system includes different interacting components, such as a surveillance camera with its server or an infusion pump with an electronic health record (EHR), you can capture any network traffic between them. Known attacks such as ARP cache poisoning can usually be performed on a single L3 segment.
Ideally, you should also run these traffic collection tools directly on the devices to capture potential inter-process communication (IPC) traffic on the local host. You may have difficulty running them on embedded devices that don’t usually have these tools installed, as there is no easy process to set them up. But we were often able to cross-compile and install tools like tcpdump even on devices with very limited administrative resources, such as home pacemaker monitoring systems. We will demonstrate this in Section 6.
After you have prepared a representative sample of network traffic, you can start analyzing it. Determine whether insecure communication channels are used: plaintext protocols; Protocols such as the Universal Plug and Play (UPnP) network protocol suite are known to be vulnerable. and proprietary protocols that require further study or may be revised (discussed in the next section).
Reverse engineering of communication protocols
You need to rethink (refactor) any proprietary communication protocol you find. Creating new protocols is always a double-edged sword; Some systems require their own protocol stack for performance, functionality, or even security. But developing and deploying a reliable protocol is often quite difficult. Most IoT systems we’ve seen use TCP or UDP and are built around them, often using some variation of XML, JSON, or another structured language. In challenging cases, we have encountered proprietary wireless protocols with little public information, such as those found in implantable pacemakers. In such cases, it is easier to study the protocols from a different perspective. For example, trying to debug system services that interact with the driver layer responsible for transmitting radio signals. So you don’t need to analyze your own wireless protocol. Instead, you can understand how it works – understand the level directly above it.
We used this method when evaluating a pacemaker. To do this, they resorted to tools such as a route attached to the processes that interact with the driver layer. By analyzing logs and pcap files, we determined the underlying communication channel without analyzing radio signals or other time-consuming methods such as Fourier transforms applied to the native wireless channel. The Fourier transform decomposes signals into frequency components.
Exploits by protocol or service
As a final step in a network attack, you should try to use a listening protocol or exploit by writing a proof-of-concept program. It is important to determine the exact conditions necessary for an exploit to occur. Does the exploit play 100% of the time? Does the system have to be in a certain state? Is the firewall blocking incoming and outgoing traffic? Can you gain the authority of a system owner after successfully attacking it? Make sure you get reliable answers to these questions.
Wireless protocol testing
We devote an entire section of this chapter to wireless protocol testing, given the prevalence of short-, medium-, and long-range radio protocols in IoT ecosystems. This layer may coincide with what other publications call the “perception layer” and includes recognition technologies such as radio frequency identification (RFID), global positioning system (GPS), and near field communication (NFC).
The process of analyzing these technologies overlaps with the actions at the network level described above (see subsections “Network Traffic Analysis” and “Reverse Engineering Protocols”). Analyzing and attacking wireless protocols typically requires specialized hardware, including: certain Wi-Fi chipsets with data entry capabilities, such as Atheros; USB-Bluetooth modules such as Ubertooth; Software Defined Radios (SDRs) such as HackRF or LimeSDR.
In this step, you will try specific attacks specific to the particular wireless protocol you are using. For example, if any IoT components use Wi-Fi, test attacks based on user impersonation or vulnerabilities in the Wired Equivalent Privacy (WEP) protocol (it will be red-flagged because it is easy to crack) and implementations of unsecured secure Wi-Fi access ( WPA/WPA2) with weak credentials. WPA3 may soon fall into this category of insecure protocols. We cover the most important attacks on these protocols in Chapters 10-13. Custom protocols should be checked for lack of authentication (including lack of mutual authentication) and lack of encryption and integrity checks, which unfortunately we see quite often, even in critical infrastructure devices.
Web applications, including those used in IoT systems, provide one of the easiest entry points into the network because they are often externally accessible and have many vulnerabilities. Evaluating web applications is a huge topic, and there are tons of resources out there to help you do just that. So, we will focus on techniques that apply specifically to web applications used in IoT devices. In fact, they are not significantly different from any other existing ones. However, those on embedded devices are often known to lack a secure software development lifecycle, resulting in obvious and known vulnerabilities. Resources for web application testing include the Web Application Hacker’s Guide and all OWASP projects, which include the Top 10 Risk List, the Application Security Verification Standard (ASVS), and the OWASP Testing Guide.
Application mapping
To map a web application, first check the visible, hidden, and default website content. Define data entry points and hidden fields and list all options. Automated crawlers (data analysis software that scans websites one page at a time) can help speed up this process, but you should also always review sites manually. You can use an interceptor proxy for passive crawling (monitoring web content while browsing manually) and as an active crawl (actively crawling a site using previously discovered URLs and embedded JavaScript AJAX requests as starting points).
You can discover hidden content or web application endpoints that are not normally accessible through visible hyperlinks by trying to enter common folder names and file names/extensions in the panel. Note that this can be quite noticeable activity as all these requests will generate a lot of network traffic. For example, the average list of typical folder and file names for the web analytics tool DirBuster contains 220,560 entries. This means that if you use it, it will send at least 220,560 HTTP requests to the object in hopes of discovering hidden URLs. But this step should not be skipped, especially if the evaluation is performed in a controlled environment. Sometimes we see very interesting, often unauthenticated web application endpoints on IoT devices. For example, we once discovered a hidden URL for a popular surveillance camera model that allows pictures to be taken without authentication, essentially allowing an attacker to remotely control what the camera is pointing at!
It is also important to define the entry points where the web application can receive user data. Most vulnerabilities in web applications occur when the application receives untrusted input from unauthenticated remote participants. You can use these entry points later to obfuscate (an automatic way of providing incorrect random data as input) and test the implementation.
Client-side controls
You can use client-side controls, meaning anything handled by a browser, native app, or mobile device. Client-side controls can be hidden fields, cookies, and Java programs. Other examples are JavaScript, AJAX, ASP.NET ViewState, ActiveX, Flash or Silverlight. For example, we’ve seen many web applications on embedded devices that perform client-side user authentication that an attacker can bypass because the user can control everything that happens on the client-side. The devices used JavaScript or .jar, .swf, and .xap files that attackers could decompile and modify to accomplish their task.
Authentication
Look for vulnerabilities in the application’s authentication mechanism. It is a well-known fact that a huge number of IoT systems come with insecure pre-configured credentials, and that users often leave these credentials unchanged. These credentials can be found by consulting manuals or other online resources, or simply by choosing. When testing IoT systems, we encountered login/password pairs ranging from the popular admin/admin to a/a (yes, username “a”, password “a”!), and sometimes no authentication was used at all. To crack non-standard passwords, perform dictionary brute-force attacks on all authentication endpoints. Such attacks use automated means to sift through passwords using the most common dictionary words or lists of passwords obtained as a result of leaks. Almost every security assessment report we compile includes a “lack of brute force protection”, embedded IoT devices often have limited hardware resources and may not maintain state as SaaS applications should.
Also, check for insecure credential transfer (which usually includes HTTP access by default, without redirecting to HTTPS); check all “Forgot password” and “Remember me” functions; Enumeration of usernames (guess and list of valid users). Look for open failure conditions that fail to authenticate, but on some exception, the application grants public access.
Session management
Web application sessions are sequences of HTTP transactions associated with a single user. Session management or the process of tracking these HTTP transactions can become complex, so test these processes for weaknesses. Check the use of implied tokens, insecure token transfer, and token disclosure in the logs. You may also discover insufficient session times, session capture vulnerabilities, and cross-site request forgery (CSRF) attacks, where authenticated users can be manipulated to perform unwanted actions.
Access control and authorization
Next, make sure the access controls are applied to the site correctly. User-level segregation, or the practice of giving users with different privileges access to different data or functions, is a common feature of IoT devices. Another name for this tactic is role-based access control (RBAC). It is especially often used in complex medical systems. For example, in an electronic medical record access system, doctors are given more privileged access than nurses, who can only be assigned read access. Likewise, the camera system will have at least one administrator account authorized to change configuration settings and a less privileged view-only account that allows the device operator to view the camera feed. But for this system to work, you need to use appropriate access control. We’ve seen systems that can request a privileged operation from a non-privileged account simply by knowing the correct URL or HTTP request. If the system supports multiple accounts, check all privilege restrictions. For example, can guest accounts access features of the web application that only administrators should be able to use? Can a guest account access an admin API managed by a different authorization framework?
Input validation
Ensure that the application properly validates and sanitizes user input for all entry points. This action is critical because the most popular type of vulnerability in web applications is input, where users can send their own code to an application disguised as user data (see “Top 10 IoT Risks” from the OWASP documentation package). Application injection testing can be very time-consuming because it involves testing for all types of incoming attacks, including SQL injection, cross-site scripting (XSS), operating system command injection, and external XML object injection (XXE ).
Logical errors
Check for vulnerabilities due to logical errors. This task is especially important when the web application has multi-step processes in which one action must follow another. If, as a result of performing these actions in the wrong order, the application goes into an unintended and undesirable state, it means that the application has a logical flaw. Most often, detecting errors in logic is a manual process that requires special knowledge of the application and the field for which it is intended.
Application server
Make sure the server is securely hosting the application. A secure web application hosted on an insecure application server loses its security capabilities. Server Security Testing: Use vulnerability scanners to detect application server errors and open vulnerabilities. Also watch for deserialization attacks and make sure your web application firewalls are secure. Make sure your server is configured correctly, such as directory listings, default content, and risky HTTP methods. You can also assess the reliability of SSL/TLS by looking for weak ciphers, self-signed certificates, and other common vulnerabilities.
The host configuration probe process evaluates the system from the inside after you have local access. For example, this verification can be performed from a local user account on the Windows server component of the IoT system. After logging in, assess various technical aspects, including user accounts, remote support connections, file system access controls, exposed network services, insecure server configurations, and more.
Accounts
Check how secure user accounts are configured in the system. This step includes verifying the existence of default user accounts and verifying the persistence of account policies. Such policies include password history (whether old passwords can be reused and, if so, when they can be reused), password expiration (how often the system forces users to change passwords), and lockout mechanisms (how many login attempts a user is allowed before how the system will block his access to the account). If the IoT device belongs to a corporate network, consider the company’s security policy to ensure account consistency. For example, if your organization’s security policy requires users to change their passwords every six months, ensure that all accounts comply with that policy. Ideally, if the system allows account integration with Active Directory or LDAP, the company can centrally enforce these policies through the server.
This stage of testing may seem too routine, but it is one of the most important. Attackers often take advantage of insecure account settings that are not centrally managed, and as a result, they end up going undetected. During testing, we often find local user accounts with a password that is identical to the login and is set indefinitely.
Password strength
Check the validity of the user account password. Password strength is important because attackers can guess weak credentials using automated tools. Ensure password complexity requirements are met via local or group policy on Windows and Plug-in Authentication (PAM) on Linux systems, with one caveat: authentication requirements will not be met. affects workflow. Consider the following scenario: a surgical system uses a complex 16-character password and blocks the user from accessing the account after three incorrect attempts. This is an easy path to disaster when a surgeon or nurse finds themselves in an emergency situation and has no other way to authenticate to the system. In cases where the patient’s moment and life are at stake, the security system should not become an insurmountable obstacle.
Account Privileges
Make sure that accounts and services are configured with least privilege – in other words, they can only access the resources they need and no more. We usually see poorly configured software without granular privilege separation. For example, often the main process does not drop elevated privileges when it no longer needs them, or the system allows different processes to run under the same account. These processes typically require access to only a limited set of resources, and if the restriction rule is not respected, they accumulate too many privileges; Once compromised, they give the attacker complete control over the system. We also often find simple logging services running with SYSTEM or root privileges. “Excessive Privilege Risk” is a note we make in almost every security assessment report we do.
In particular, on Windows systems, the problem can be solved with the power of managed service accounts, which allow you to isolate domain accounts used by critical applications and automate the management of their credentials. On Linux systems, the use of security mechanisms such as capabilities, seccomp, SELinux, and AppArmor will help limit process privileges and strengthen the security of the operating system. Additionally, solutions such as Kerberos, OpenLDAP, and FreeIPA are useful for account management.
Patch levels
Make sure your operating system, applications, and all third-party libraries are up-to-date and updated regularly. Patches are important, complex, and often underappreciated. Testing legacy software may seem like a routine task (which can usually be automated with vulnerability scanning tools), but a completely updated ecosystem is almost nowhere to be found. To identify open source components with known vulnerabilities, use software composition analysis tools that automatically check third-party code for patches. You can rely on authenticated vulnerability scans or even manually check for missing operating system patches. Be sure to check if your IoT device vendors support the latest Windows or Linux kernel; You will be convinced more than once that this is not the case.
Update system components are one of the weaknesses of the information security industry and especially the Internet of Things world. One of the main reasons is that embedded devices are inherently more susceptible to change: they often use complex, immutable firmware. Another reason is that updating and patching some systems, such as ATMs, on a regular basis can be prohibitively expensive due to the high cost of downtime (the time customers cannot access the system) and the amount of work involved. For highly specialized systems such as medical devices, the vendor must first perform extensive testing before releasing a new patch. You don’t want your blood analyzer giving a false positive on your hepatitis test because of the floating point error caused by the latest update! What about an implantable pacemaker upgrade? Updates must literally be a matter of life and death to justify calling every patient to the doctor to solve the problem.
In testing, we often see third-party software being used without updates, even if the core components are up to date. Typical examples on Windows are Java, some Adobe products, and even Wireshark. Outdated versions of OpenSSL are common on Linux devices. Sometimes software is installed for no particular purpose and it is better to uninstall it rather than trying to install a fix process for it. Why install Adobe Flash on the server that exchanges data with the ultrasound machine?
Remote maintenance
Make sure the remote service is secure and the device supports the connection. Often, instead of sending the device to the vendor for rework, the organization calls the vendor and invites technical support staff to remotely connect to the system. Attackers sometimes use the remote connection functionality as a loophole to grant administrative access. Most of these methods are dangerous. An example is the Target hack, where attackers gained access to the store’s core network through a third-party HVAC company.
Vendors can update devices remotely, but this is generally not the best way to keep IoT devices on your network up to date. Because some of these devices are too sensitive and complex, employees can’t just start secretly installing updates on them; There is always a chance to break something. And what to do if the device fails at the most acute moment (take, for example, a computer tomography in a hospital or a critical temperature sensor at a power plant)?
It is important to evaluate not only the remote support software (ideally by reengineering its binaries) and its communication channel, but also the established remote maintenance process. Does the facility use 24/7 communication? Is there two-factor authentication when connecting the provider? Is there a magazine?
Make sure that the principle of least privilege mentioned earlier in this chapter applies to key files and directories. Often, low-privileged users can read and write important directories and files (such as service executables), making privilege escalation attacks easier. Do non-administrators really need write access to C:\Program Files? Do users need access to /root? We once evaluated an embedded device with several startup scripts that were available for modification by normal users, allowing an attacker to use local access to run their own programs as root and gain full control of the system.
Data encryption
Make sure sensitive data is encrypted. First, identify the most sensitive data, such as protected health information (PHI) or personally identifiable information. PHI includes any record of health, provision or payment of health care services, while PII (personally identifiable information) is any data that can potentially identify a specific individual. Ensure that this data is encrypted by checking your system configuration for cryptographic primitives. If someone manages to steal the device’s drive, will they be able to read the data? Does it use Full Disk Encryption, Database Encryption, or any other encryption, and how cryptographically strong is it?
Incorrect server configuration
Incorrectly configured services can be dangerous. For example, you can still find FTP servers that have guest access enabled by default, allowing attackers to connect anonymously and read or write to specific folders. We once discovered Oracle Enterprise Manager running as SYSTEM and accessible remotely with default credentials, which allowed attackers to execute operating system commands by abusing Java stored procedures. This vulnerability allowed attackers to completely compromise the system over the network.
Test the security of any mobile application connected to an IoT system. These days, developers often create apps that work on Android and iOS for just about anything – even pacemakers! For more information on mobile app security testing, see Chapter 14. Also, check out OWASP’s Top 10 Mobile Apps, Mobile Security Testing Guide, and Mobile App Security Validation Standard.
In a recent evaluation, we discovered that the app sends personal health data to the cloud without the knowledge of the doctor or nurse operating the device. This is not actually a technical vulnerability, but a serious privacy breach that interested parties should be aware of.
Also assess the security status of any cloud component connected to the IoT system. Explore compatibility between cloud and IoT components. Pay close attention to server-side APIs and implementations on cloud platforms, including but not limited to AWS, Azure, and Google Cloud Platform. Vulnerabilities related to insecure direct object references are common (IDOR) vulnerabilities, which allow anyone who knows the correct URL to access sensitive data. For example, AWS sometimes allows an attacker to gain access to so-called S3 buckets by using a URL associated with the data objects that the bucket contains.
Many of the tasks associated with cloud testing will overlap with the security assessment of mobile and web applications. In the first case, the reason is that the client using these APIs is usually an Android or iOS app. In the latter case, we take into account that many cloud components are mainly web services. You can also test any cloud connections for remote maintenance and support as described in the Host Configuration Overview section.
We were able to identify a number of cloud services with vulnerabilities: hard-coded cloud tokens, API keys embedded in mobile apps and firmware binaries, lack of TLS certificate pinning, and vulnerability of intranet services (such as an unauthenticated Redis cache server or metadata service) to the public due to misconfiguration . Keep in mind that you need permission from the owner of the cloud services to perform any testing in the cloud.
Some members of our team worked in the cyber defense departments of the armed forces. There we learned that due diligence is one of the most important aspects of information security. It is important to follow the security testing methodology to avoid missing some obvious things. It’s easy to miss existing vulnerabilities simply because they seem too simple.
Therefore, this section examines the testing methodology for performing security assessments of IoT systems. We discussed passive research and then described the layers (physical, network, cloud, web, host, and mobile app) and divided them into smaller segments.
The levels mentioned in this section are rarely found in pure form; there may be overlaps between two or more levels. For example, a battery drain attack can be part of the physical layer assessment, since the battery is a hardware device, or part of the network layer, since an attacker can launch an attack through the component’s wireless network protocol. The list of components to evaluate is also not exhaustive, so we will provide links to additional resources as necessary.
We used materials from the book “The Definitive Guide to Attacking the Internet of Things” written by Photios Chantsis, Ioannis Stais, Paulino Calderon, Evangelos Deirmentsoglu and Beau Woods.
1179 
917 
1068 
885 
1146 
1022 
1015 
1012 
1011 
985 
1430