A Security Testing Methodology rednike tech cyber security

A Security Testing Methodology

 Security Testing Guide Full Artcial read and like 

Which methods techniques are used for security testing Best Exports And Follow This Page

What is security assessment methodology Advence technology

Cloud Information Testing

Cloud testing is the most common way of testing programming applications conveyed on distributed computing assets in a foundation as a help (IaaS) model, or served by outsider specialist co-ops in a stage as an assistance (PaaS) or programming as an assistance (SaaS) model.

Cloud information testing can guarantee ideal information execution, accessibility, and security, and limit personal time of the significant foundation or stage.

A focal point of cloud information testing is to guarantee that commitments made by cloud and SaaS suppliers are satisfied. For instance, cloud information testing can check that suppliers are meeting execution SLAs, test assuming information is really repeated to a few areas, and confirm that calamity recuperation processes are working accurately.

Where do you start when you want to test an IoT system for vulnerabilities? If the attack surface is small enough, as in the case of a single web portal that controls a surveillance camera, planning a security test might be simple. Even then, however, if the testing team doesn’t follow a set methodology, they might miss critical points of the application.

This chapter provides you with a rigorous list of steps to follow when penetration testing. To do so, we’ll divide the IoT attack surface into conceptual layers, as shown in Figure 3-4.

f03001

Figure 3-4 The conceptual layers to test in a security assessment

You’ll need a robust assessment methodology like this one when testing IoT systems because they often consist of many interacting components. Let’s use the case of a pacemaker connected to a home monitoring device. The monitoring device can send patient data to a cloud portal through a 4G connection so the clinicians can check for heart-rate anomalies. Clinicians can also configure the pacemaker using a programmer that relies on a near-field communication (NFC) wand and proprietary wireless protocol. This system has many parts, each with a potentially substantial attack surface, which a blind, unorganized security assessment would most likely fail to map successfully. To make the assessment successful, we’ll walk through passive reconnaissance, and then discuss methods of testing the physical, network, web application, host, mobile application, and cloud layers.

Passive Reconnaissance

Passive reconnaissance, also commonly referred to as open source intelligence (OSINT), is the process of collecting data about targets without communicating directly with the systems. It’s one of the initial steps for any assessment; you should always perform it to get the lay of the land. For example, you might download and examine device manuals and chipset datasheets, browse online forums and social media, or interview users and technical personnel for information. You could also gather internal hostnames from TLS certificates released as a result of Certificate Transparency, a standard that requires Certificate Authorities to publish the certificates they issue in a public log record.

Manuals and Documents

System manuals can provide a trove of information about the inner workings of devices. You can usually find them on the device vendor’s official website. If that fails, try advanced Google searches for PDF documents containing the device name: for example, by searching for the device and in the query.

It’s surprising how much important information you can find in manuals. Our experience shows they can reveal default usernames and passwords that often still remain in production environments, detailed specifications of the system and its components, network and architecture diagrams, and troubleshooting sections that help identify weak spots.

If you’ve identified certain chipsets installed on the hardware, it’s also worthwhile to look for the relevant datasheets (manuals for electronic components), because they might lay out the chipset pins used for debugging (such as the JTAG debug interfaces discussed).

Another useful resource, for devices that use radio communication, is the FCC ID online database at https://fccid.io/. An FCC ID is a unique identifier assigned to a device registered with the United States Federal Communications Commission. All wireless emitting devices sold in the United States must have an FCC ID. By searching for a specific device’s FCC ID, you can find details on the wireless operating frequency (such as its strength), internal photos of the device, user manuals, and more. The FCC ID is usually engraved on the case of the electronic component or device (Figure 3-2).

f03002

Figure 3-2 The FCC ID shown on the RFM95C chip of the CatWAN USB stick, which we’ll use in for LoRa hacking

Patents

Patents can provide information about the inner workings of certain devices. Try searching for a vendor name at https://patents.google.com/ and see what comes up. For example, the keywords “medtronic bluetooth” should pull up a patent for a communication protocol between implantable medical devices (IMDs) published in 2004.

The patents will almost always contain flow diagrams that could help you when assessing the communication channel between the device and other systems. In Figure 3-3, a simple flow diagram for the same IMD shows a critical attack vector.

Notice that arrows enter and leave the IMD column. The remote system’s /Patient action & advise/  action can initiate a connection to the device. When you follow the chain of arrows, notice that the action can also update the device’s programming to change python settings that could harm the patient. For this reason, the remote system creates risks of remote compromise, either through an insecure mobile app or the actual remote system (usually implemented on the cloud).

f03003

Figure 3-3 The flow diagram from the Medtronic patent shows that bidirectional communication can occur between the device and a remote system through a mobile phone. This highlights an important attack vector.

User Knowledge

It’s amazing how much public information you can find on social media, online forums, and chat rooms. You can even use Amazon and eBay reviews as a knowledge source. Look for users complaining about certain device functions; buggy behavior can sometimes indicate an underlying vulnerability. For example, you might find a user complaining about the device crashing after triggering a set of conditions. This is a good lead to investigate, because it can point to a logic bug or a memory corruption vulnerability resulting from specific input to the device. In addition, many users post detailed product reviews with specifications and disassembly photos.

Also, check profiles or posts on LinkedIn and Twitter. Engineers and IT personnel working for the IoT system’s manufacturer might expose juicy tidbits of technical information. For example, if the person posts that they have a strong background on a specific CPU architecture, it’s very likely that many of the manufacturer’s devices are built using that architecture. If another employee rants about (or praises, although this happens less often) a specific framework, there’s a considerable chance the company uses that framework to develop software.

In general, each IoT industry will have its own set of experts that you can consult for useful information. For instance, if you were assessing a power plant, asking the operators or technicians about their workflows could prove valuable for determining potential attack vectors. In the medical world, nurses are usually the sysadmins and main operators of IoT systems. Hence, they typically have ample knowledge about the device’s ins and outs, and you should consult with them if possible.

The Physical or Hardware Layer

One of the most important attack vectors in an IoT device is the hardware. If attackers can get ahold of a system’s hardware components, they’re frequently able to gain elevated privileges, because the system almost always implicitly trusts anyone who has physical access. In other words, if a dedicated adversary has physical access to your systems, you can pretty much consider the game over. Assume that the most motivated threat actors, such as nation state–funded ones with virtually infinite time and resources, will have a physical copy of the device available to them. Even for special-purpose systems, such as large ultrasound machines, adversaries can get the hardware from online marketplaces, companies that dispose of devices insecurely, or even theft. They don’t even need the exact version of the device. Often, vulnerabilities span many generations of a system.

An assessment of the hardware layer should include testing for peripheral interfaces, the boot environment, physical locks, tamper protection, firmware, debug ports, and physical robustness.

Peripheral Interfaces

Peripheral interfaces are physical communication ports that allow you to connect external devices, such as keyboards hard disks, and network cards. Check whether any active USB ports or PC card slots are enabled and whether they’re bootable. We’ve gained administrative access to a large variety of x86 systems by booting our own operating system on the device, mounting the unencrypted filesystem, extracting crackable hashes or passwords, and installing our own software on the filesystem to override technical security controls. You could also extract hard disks and read from or write to them even without access to bootable USB ports, although this technique is less convenient. Note that tampering with the hardware to extract the disks might damage the components.

USB ports can be attack vectors for another reason some, mostly Windows-based devices have a kiosk mode, which restricts the user interface Consider the ATM machine you use to withdraw cash even though in the backend it might run on the Windows XP embedded operating system, the user sees only a restricted graphical interface with a specific set of options. Imagine what you could do if you could attach a USB keyboard to an exposed port on the device. Using specific key combinations, such as Ctrl-Alt-Delete or the Windows key, you might be able to escape the kiosk mode and gain direct access to the rest of the system.

Boot Environment

For systems using a conventional BIOS (typically x86 and x64 platforms), check whether the BIOS and boot loader are password-protected and what the preferred boot order is. If the system boots removable media first, you can boot your own operating system without having to make any changes to the BIOS settings. Also, check whether the system enables and prioritizes Preboot Execution Environment (PXE), a specification that allows clients to boot through the network using a combination of DHCP and TFTP. This leaves room for attackers to set up rogue network boot servers. Even if the boot sequence is securely configured and all settings are password-protected, you can normally still reset the BIOS to its default, clean, and unprotected settings (such as by temporarily removing the BIOS battery). If the system has Unified Extensible Firmware Interface (UEFI) Secure Boot, assess its implementation as well. UEFI Secure Boot is a security standard that validates that the boot software hasn’t been tampered with (by rootkits, for example). It does so by checking the signature of the UEFI firmware drivers and the operating system.

You might also encounter Trusted Execution Environment (TEE) technologies such as TrustZone in Arm platforms or Qualcomm Technologies secure boot feature which verify secure boot images

Locks

Check whether the device is protected by some kind of lock, and if it is, how easy it is to pick the lock. Also check whether there’s a universal key for all locks or a separate one for every device. In our assessments, we’ve seen cases where all devices by the same manufacturer used the same key, rendering the lock useless, because anyone in the world could easily have a copy of the key. For example, we found that a single key could unlock an entire product line of cabinets that gave physical access to a drug infusion pump’s system configuration

To assess locks you’ll need a lockpicking tool set in addition to knowledge of the type of target lock in use For example a tumbler lock opens differently than an electric-powered lock which might fail to open or close if power is off

Tamper Protection and Detection

Check whether the device is tamper-resistant and tamper-evident. For example, one way to make a device tamper-evident is to use a label with perforated tape that permanently displays some kind of message after it’s opened. Other tamper protections include effuses, tamper clips, special enclosings sealed with epoxy, or physical fuses that can erase sensitive contents if a device is disassembled. Tamper detection mechanisms send an alert or create a log file on the device upon sensing an attempt to compromise the device’s integrity. It’s especially important to check for tamper protection and detection when conducting a penetration test of IoT systems within an enterprise. Many threats come from the inside, caused by employees, contractors, or even former employees, so having tamper protection can help identify any purposefully altered device. An attacker would have trouble disassembling a tamper-resistant device.

Firmware

We’ll cover firmware security in detail in so we won’t expand on it here. But keep in mind that accessing firmware without permission can have legal consequences. This matters if you plan to publish security research that involves accessing the firmware or reverse engineering the executables found in it. Refer to IoT Hacking Laws on page 12 for information about navigating this legal environment.

Debug Interfaces

Check for debug, services, or test pointinterfaces that the manufacturer might have used to simplify development, manufacturing, and debugging. You’ll commonly find these interfaces in embedded devices, and you can exploit them to gain immediate root access. We wouldn’t have fully understood many of the devices we’ve tested without first opening a root shell on the systems by interfacing with debug ports, because there was no other way to access and inspect the live system. Doing so might first require some familiarity with the inner workings of the communication protocols these debug interfaces use, but the end result is usually well worth it. The most common types of debug interfaces include UART, JTAG, SPI, and I2C. We’ll discuss these interfaces

Physical Robustness

Test for any limitations posed by the hardware’s physical characteristics. For example, assess the system for battery drain attacks, which occur when an attacker overloads the device and causes it to run out of battery in a short period of time, effectively causing a denial of service. Consider how dangerous this is when done to an implantable pacemaker on which a patient’s life relies. Another type of test in this category is glitching attacks, intentional hardware faults introduced to undermine security during sensitive operations. In one of our most surprising successes, we made the booting process of an embedded system drop a root shell when we performed a glitching attack on its printed circuit board (PCB). Additionally, try side-channel attacks like differential power analysis, which tries to measure the power consumption of a cryptographic operation to derive secrets.

Examining the device’s physical characteristics can also help you make educated guesses about the robustness of other security features. For example, a tiny device with a long battery life might have weak forms of encryption in its network communication. The reason is that the processing power required for stronger encryption would drain the battery faster and the battery has a limited capacity due to the device’s size.

The Network Layer

The network layer which includes all components that directly or indirectly communicate through standard network communication paths is usually the largest attack vector  So we’ll break it into smaller parts reconnaissance network protocol and service attacks, and wireless protocol testing

Although many of the other testing activities covered in this chapter involve the network, we’ve given those activities their own sections when necessary. For example. web application assessment has its own section because of its complexity and the sheer amount of testing activities involved

Reconnaissance

We’ve already discussed steps you can take to perform passive reconnaissance on IoT devices generally In this section we outline active and passive reconnaissance for networks specifically one of the first steps for any network attack. Passive reconnaissance might include listening on the network for useful data, whereas active reconnaissance (reconnaissance that requires interacting with the target) requires querying devices directly

For a test on a single IoT device, the process is relatively simple, because there’s only one IP address to scan. But for a large ecosystem, such as a smart home or health care environment with medical devices, network reconnaissance can be more complicated. We’ll cover host discovery, service version detection, operating system identification and topology mapping.

Host Discovery

Host discovery is determining which systems are live on the network by probing them using a variety of techniques. These techniques include sending Internet Control Message Protocol (ICMP) echo-request packets, conducting TCP/UDP scans of common ports, listening for broadcast traffic on the network, or conducting ARP request scans if the hosts are on the same L2 segment. (L2 refers to the layer 2 of the OSI model of computer networking. It is the data link layer and is responsible for transferring data between nodes on the same network segment across the physical layer. Ethernet is a common data link protocol.) For complex IoT systems, such as servers managing surveillance cameras that span many different network segments, it’s important to not rely on any one particular technique. Rather, leverage a diverse set to increase the chances of bypassing firewalls or strict VLAN (Virtual Local Area Network) configurations.

This step might be the most useful in cases where you’re conducting a penetration test of IoT systems in which you don’t know the IP addresses of the tested systems.

Service Version Detection

After you’ve identified live hosts, determine all the listening services on them. Begin with TCP and UDP port-scanning. Then conduct a combination of banner grabbing (connecting to a network service and reading the initial information it sends back as a response) and probing with service fingerprinting tools, such as Amap or Nmap’s -sV option. Be aware that some services, especially on medical devices, are particularly prone to breaking with even simple probing. We’ve seen IoT systems crash and reboot simply because we scanned them with Nmap’s version detection functionality. This scan sends specially crafted packets to elicit responses from certain types of services that otherwise don’t send any information when you connect to them. Apparently, those same packets can make some sensitive devices unstable because the devices lack robust input sanitization on their network services, leading to memory corruption and then crashes.

Operating System Identification

You’ll need to determine the exact operating system running on each of the tested hosts so you can develop exploits for them later. At the very least, identify the architecture (for example, x86, x64, or ARM). Ideally, you’d identify the operating system’s exact service pack level (for Windows) and kernel version (for Linux or Unix-based systems in general).

You can identify an operating system through the network by analyzing the host’s responses to specially crafted TCP, UDP, and ICMP packets, a process called fingerprinting. These responses will vary because of minor differences in the implementation of the TCP/IP network stack in different operating systems. For example, certain older Windows systems respond to a FIN probe against an open port with a FIN/ACK packet; others respond with an RST, and still others don’t respond at all. By statistically analyzing such responses, you can create a profile for each operating system version, and then use these profiles to identify them in the wild. (For more information, visit the Nmap documentation’s “TCIP/IP Fingerprinting Methods Supported by Nmap” page.)

Service scanning can also help you perform operating system fingerprinting, because many services expose system information in their banner announcements. Nmap is a great tool for both jobs. But be aware that for some sensitive IoT devices, operating system fingerprinting can be intrusive and can cause crashes.

Topology Mapping

Topology mapping models the connections between different systems in a network. This step applies when you have to test an entire ecosystem of devices and systems, some of which might be connected through routers and firewalls and aren’t necessarily on the same L3 segment. (L3 refers to the layer 3 of the OSI model of computer networking. It is the network layer and is responsible for packet forwarding and routing. Layer 3 comes into play when data is transferred through routers.) Creating a network map of the tested assets becomes useful for threat modeling: it helps you see how an attack that exploits a chain of vulnerabilities in different hosts can lead to a critical asset compromise. Figure 3-4 shows a high-level topology diagram.

f03004

Figure 3-4 A simple topology diagram of a home network that includes a home monitoring device for a patient with an IMD

This abstract network map shows a patient who has an IMD communicating with a home monitoring device. The home device in turn relies on the local Wi-Fi connection to send diagnostic data to the cloud where a physician can monitor them periodically to detect any anomalies.

Network Protocol and Service Attacks

Network protocol and service attacks consist of the following stages vulnerability scanning, network traffic analysis protocol reverse engineering and protocol or service exploitation. Although you can carry out vulnerability scanning independently of the other stages, the rest depend on one another.

Vulnerability Scanning

Start by checking databases, such as the National Vulnerability Database (NVD) or VulnDB for any known vulnerabilities in the exposed network services. Sometimes the system is so out-of-date that an automated vulnerability scanning tool will fill pages and pages of reports. You might even be able to exploit certain vulnerabilities remotely with no authentication. For due diligence, run at least one scanning tool to quickly identify low-hanging fruit. If you find a serious vulnerability, such as remote code execution, you might be able to get a shell on the device, which will help you with the rest of the assessment. Make sure you always scan in a controlled environment and closely monitor it in the event that unforeseen downtime occurs

Network Traffic Analysis

Early in the security assessment process, leave a traffic-capturing tool like Wireshark or tcpdump running for a period of time to get an idea of the communication protocols in use. If the IoT system involves different interacting components, such as a surveillance camera with its server or a drug infusion pump with an EHR system, you should be able to capture any network traffic traveling between them. Known attacks, such as ARP cache poisoning, will usually do the trick on the same L3 segment.

Ideally, you’ll also run these traffic-capturing tools directly on the devices to capture potential interprocess communication (IPC) traffic on the localhost. You might have more difficulty running these network tools on embedded devices, which won’t usually have these tools already installed, because there’s no straightforward process to set them up. But we’ve often succeeded in cross-compiling and installing tools like tcpdump on even very restrictive devices, such as pacemaker home monitoring systems. We’ll demonstrate
After you’ve captured a representative sample of network traffic you can begin analyzing it Determine whether there are insecure communication channels, like cleartext protocols known vulnerable protocols, like the Universal Plug and Play (UPnP) set of networking protocols; and proprietary protocols that need further examination or reverse engineering discussed in the following section

Reverse Engineering Protocols

You should reverse engineer any propriety communication protocols you discover. Creating new protocols is always a double-edged sword; some systems do indeed require their own protocol stack for their performance, functionality, or even security. But designing and implementing a robust protocol is usually a very complicated task. Many of the IoT systems we’ve seen leverage TCP or UDP and build on top of them, often using some variant of XML, JSON, or other structured language. In complex cases, we’ve encountered proprietary wireless protocols about which there is little to no public information available, such as those found in implantable pacemakers. In these cases, it might be easier to examine the protocols from a different angle. For example, try to debug the system services that communicate with the driver layer that is responsible for transmitting the radio signal. This way, you won’t necessarily have to analyze the proprietary wireless protocol. Instead, you might be able to figure out how it works by understanding the layer just above it.

For example, we used this technique when assessing a pacemaker. To do so, we leveraged tools, such as strace, that attached to the processes communicating with the driver layer. By analyzing logs and pcap files, we identified the underlying communication channel without having to conduct radio-signal analysis or other time-consuming methods, like Fourier transforms, on the proprietary wireless channel. Fourier transforms decompose signals into their constituent frequencies.

Protocol or Service Exploitation

As the last step in a network attack, you should actually exploit the protocol or listening service by writing a proof-of-concept program that abuses it. Crucially, you’ll have to determine the exact conditions required for exploitability. Is the exploit reproducible 100 percent of the time? Does it require the system to be in a certain state first? Does a firewall rule prevent ingress or egress communication? Is the system usable after you’ve successfully exploited it? Make sure you come up with solid answers to these questions.

Wireless Protocol Testing

We’re dedicating an entire section to wireless protocol testing because of the prevalence of short, medium, and long-range radio communication protocols in IoT ecosystems. This layer can coincide with what other literature describes as the Perception Layer, which includes sensing technologies like Radio-Frequency Identification (RFID), Global Positioning System (GPS), and Near-Field Communication (NFC).

The process of analyzing these technologies overlaps with the Network Layer’s Network Traffic Analysis and the Reverse Engineering Protocols activities earlier in this chapter. Analyzing and attacking wireless protocols usually requires specialized equipment, including certain injection-capable Wi-Fi chipsets, like Atheros; Bluetooth dongles, such as the Ubertooth; and Software Defined Radio tools, like HackRF or LimeSDR

In this stage, you’ll test for certain attacks pertaining to the specific wireless protocol in use. For example, if any IoT components use Wi-Fi, test for things like association attacks, any use of Wired Equivalent Privacy (WEP) (which would be a red flag, because it’s easily crackable), and insecure Wi-Fi Protected Access (WPA/WPA2) implementations with weak credentials. WPA3 might soon belong in this category. We’ll walk through the most important attacks against these protocols in Chapters 10 through 13. For custom protocols, you’d test for a lack of authentication (including a lack of mutual authentication) and a lack of encryption and integrity checking, all of which we’ve unfortunately witnessed quite often, even in critical infrastructure devices.

Infiltration Testing Administrations

According to the most recent programming testing patterns that we have been seeing in the Quality Affirmation (QA) industry, network safety testing administrations have become one of the most sort-later and basic prerequisites in our client's QA trying system. The rising number of examples of information burglaries, protection breaks and security weaknesses that business and undertakings are confronting today has made the significance of safety testing administrations considerably more basic. To guarantee that we can effectively and dependably address our client's security trying requirements, CredibleSoft rehearses utilization of most recent industry principles and security testing systems.

Web Application Assessment

Web applications, including those used in IoT systems, provide one of the easiest network entry points, because they’re often externally accessible and riddled with a multitude of vulnerabilities. Assessing web applications is a vast topic, and a huge number of resources already exist to guide you through it. So, we’ll focus on techniques that specifically apply to web applications encountered in IoT devices. The truth is that they don’t differ significantly from almost any other web app in existence, but those found on embedded devices often notoriously lack secure software development life cycles, leading to obvious and known vulnerabilities. Resources for web application testing include The Web Application Hacker’s Handbook and all OWASP projects, such as its Top 10 list, the Application Security Verification Standard (ASVS) project, and the OWASP Testing Guide.

Application Mapping

To map a web app, begin by exploring the website’s visible, hidden, and default content. Identify data entry points and hidden fields, and enumerate all parameters. Automated spidering tools (data mining software that crawls websites one page at a time) can help speed up the process, but you should always browse manually as well. You can leverage an intercepting proxy for passive spidering (monitoring the web content as you manually browse) as well as active spidering (actively crawling the site using previously discovered URLs and AJAX requests embedded in JavaScript as starting points).

You can discover hidden content, or web app endpoints that you can’t usually reach via accessible hyperlinks, by trying common file or directory names and extensions. Note that this can be very noisy, because all these requests will generate a lot of network traffic. For instance, a medium-sized list of common directory and filenames for the DirBuster web crawling tool has 220,560 entries. This means that if you use it, it will send at least 220,560 HTTP requests to the target in the hope of discovering hidden URLs. But don’t overlook this step, especially when the assessment takes place in a controlled environment. We’ve often found some very interesting, often unauthenticated, web app endpoints in IoT devices. For example, we once uncovered a hidden URL on a popular surveillance camera model that allowed you to take pictures completely unauthenticated—essentially allowing an attacker to remotely monitor whatever the camera was pointing at!

It’s also important to identify entry points where the web application can receive user data. Most vulnerabilities in web applications occur because the application receives untrusted input from unauthenticated remote actors. You can use these entry points later for fuzzing (an automated way of providing invalid random data as input) and to test for injection.

Client-Side Controls

You might be able to exploit client-side controls, which are anything that gets processed by browser, thick, or mobile apps. Client-side controls might include hidden fields, cookies, and Java applets. They could also be JavaScript, AJAX, ASP.NET ViewState, ActiveX, Flash, or Silverlight objects. For example, we’ve seen numerous web applications on embedded devices perform user authentication on the client side, which an attacker can always 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 do their bidding

Authentication

Look for vulnerabilities in the app’s authentication mechanism. It’s common knowledge that a huge number of IoT systems come with weak preconfigured credentials and that users often leave these credentials unchanged. You can discover these credentials by referencing manuals or other online resources, or simply by guessing. When testing IoT systems, we’ve seen credentials ranging from the popular admin/admin, to a/a (yes, username a, password: a), to simply no authentication. To crack nondefault passwords, perform dictionary attacks against all authentication endpoints. A dictionary attack uses automated tools to guess a password by testing the most common words from dictionaries or leaked lists of common passwords. Almost every security assessment report we’ve written includes “lack of brute-force protection” as a finding, because IoT embedded devices often have limited hardware resources and might not be able to keep state like a SaaS application would.

Also, test for the insecure transmission of credentials (which commonly includes default HTTP access with no redirection to HTTPS); examine any “forgot password” and “remember me” functionality; perform username enumeration (guessing and listing valid users); and look for fail-open conditions in which authentication fails but, due to some exception, the app provides open access.

Session Management

Web application sessions are sequences of HTTP transactions associated with a single user. Session management, or the process of keeping track of those HTTP transactions, can get complicated, so inspect those processes for flaws. Check for the use of predictable tokens, the unsafe transmission of tokens, and disclosure of tokens in logs. You might also find insufficient session expirations, session-fixation vulnerabilities, and Cross-Site Request Forgery (CSRF) attacks in which you can manipulate authenticated users to perform unwanted actions.

Access Controls and Authorization

Next, check that the site properly enforces access controls. User-level segregation, or the practice of giving users with different privileges access to different data or functionality, is a common feature of IoT devices. It’s also known as role-based access control (RBAC). This is especially true of complex medical devices. For example, in an EHR system, the clinician account will have more privileged access than the nurse account, which might have read-only access. Similarly, camera systems will have at least an administrator account whose rights include the ability to change configuration settings and a less privileged view-only account meant to allow device operators to view the camera feed. But the systems need to have proper access controls in place for this to work. We’ve seen systems where you could request a privileged action from a nonprivileged account just by knowing the right URL or HTTP request, also known as forced browsing. If the system supports multiple accounts, test all privilege boundaries. For example, can a guest account access web app functionality that only an admin should use? Can a guest account access an admin API governed by another authorization framework?

Input Validation

Make sure the application is properly validating and sanitizing user input for all data entry points. This activity is critical, given that the most popular type of web app vulnerability is injection, in which users can submit their own code as user input to an application (see OWASP’s Top 10 list of vulnerabilities). Testing an application’s input validation can be a very lengthy process. The reason is that it includes testing for all types of injection attacks, including SQL injection, Cross-Site Scripting (XSS), operating system command injection, and XML External Entity (XXE) injection.

Logic Flaws

Check for vulnerabilities due to logic flaws. This task is especially important when the web app has multistage processes in which one action has to follow another. If performing these actions out of order causes the app to enter unintentional and undesirable states, the app has a logic flaw. Often, discovering logic flaws is a manual process that requires context about the application and the industry for which it’s developed.

Application Server

Check that the server hosting the application is secure. Having a secure web application hosted on an insecure application server defeats the purpose of securing the actual app. To test the server’s security, use vulnerability scanners to check for application server bugs and public vulnerabilities. Also, check for deserialization attacks and test the robustness of any web application firewalls. Additionally, test for server misconfigurations, like directory listings, default content, and risky HTTP methods. You might also assess the robustness of SSL/TLS, checking for weak ciphers, self-signed certificates, and other common vulnerabilities.

Host Configuration Review

The process of host configuration review assesses the system from the inside after you’ve gained local access. For example, you could perform this review from a local user account on the Windows server component of an IoT system. Once inside, evaluate a variety of technical aspects, including user accounts, remote support connections, filesystem access controls, exposed network services, insecure server configurations, and more.

User Accounts

Test how securely configured user accounts are in the system. This step includes testing for the existence of default user accounts and examining the robustness of account policies. Such policies include password history (whether and when you can reuse old passwords), password expiration (how often the system forces users to change their passwords), and lockout mechanisms (how many wrong attempts the user has to provide credentials until they’re locked out of their account). If the IoT device belongs to an enterprise network, take into account the company’s security policies to ensure that the accounts are consistent. For example, if the organizational security policy requires users to change their passwords every six months, check that all accounts comply with the policy. Ideally, if the system allows you to integrate accounts with the company’s Active Directory or LDAP services, the company should be able to enforce these policies in a centralized way through the server.

This testing step might sound mundane, but it’s one of the most important. Attackers very often abuse weakly configured user accounts that aren’t managed in a centralized way and thus end up being overlooked. In our assessments, we frequently find local user accounts that have a nonexpiring password identical to the username.

Password Strength

Test the security of the passwords on user accounts. Password strength is important because attackers can guess weak credentials using automated tools. Check whether password complexity requirements are enforced through either group or local policies on Windows and the Pluggable Authentication Modules (PAM) on Linux-based systems, with one caveat: authentication requirements shouldn’t impact business workflow. Consider the following scenario: a surgical system enforces a password complexity of 16 characters and locks users out of the account after three wrong attempts. This is a recipe for disaster when the surgeon or nurse has an emergency situation and there’s no other way to authenticate to the system. In cases where even seconds matter and patients’ lives are at stake, you must ensure that security doesn’t interfere in a negative way.

Account Privileges

Check that accounts and services are configured with the principle of least privilege, in other words, that they’re able to access only the resources they need and no more than that. We commonly see poorly configured software without fine-grained privilege separation. For example, often the main process doesn’t drop its elevated privileges when it no longer needs them, or the system lets different processes all run under the same account. These processes normally need access to only a limited set of resources, so they end up overprivileged; once compromised, they provide an attacker with full control of the system. We also frequently find simple logging services running with SYSTEM or root privileges. The high-risk finding “Services with Excessive Privileges” appears in almost every security assessment report we write.

In Windows systems specifically, you can solve this problem using managed service accounts, which let you isolate domain accounts used by critical applications and automate their credential management. On Linux systems, using security mechanisms like capabilities, seccomp (which whitelists system calls), SELinux, and AppArmor can help limit process privileges and harden the operating systems. In addition, solutions like Kerberos, OpenLDAP, and FreeIPA can help with account management.

Patch Levels

Check that the operating system, applications, and all third-party libraries are up-to-date and have an update process. Patches are important, complicated, and largely misunderstood. Testing for outdated software might seem like a routine task (which you can usually automate using vulnerability scanning tools), but almost nowhere will you find a fully up-to-date ecosystem. To detect open source components with known vulnerabilities, leverage software composition analysis tools that automatically inspect third-party code for missing patches. To detect missing operating system patches, you can rely on authenticated vulnerability scans or even check for them manually. Don’t forget to check whether the vendors still support the Windows or Linux kernel version of the IoT device; you’ll frequently find they don’t.

Patching system components is one of the banes of the information security industry, and the IoT world especially. One of the main reasons is that embedded devices are harder to patch by nature because they often rely on complex firmware that is set in stone. Another reason is that patching certain systems, like ATM machines, on a regular basis can be prohibitively expensive because of the cost of downtime—the time in which customers can’t access the system—and the amount of work involved. For more special-purpose systems like medical devices, the vendor must first perform rigorous testing before releasing any new patch. You don’t want the blood analyzer to accidentally show a positive result for hepatitis because of a floating-point error caused by the latest update, do you? And how about patching an implantable pacemaker? The update should involve a life-or-death situation (literally) to justify calling all patients to the doctor’s office to “patch them up.

In our assessments, we often see third-party software used without patches, even though core components might be up-to-date. Common examples of this on Windows include Java, Adobe, and even Wireshark. In Linux devices, it’s common to find outdated versions of OpenSSL. Sometimes the software installed has absolutely no reason to be there, and it’s best to remove it instead of trying to establish a patching process for it. Why would you need Adobe Flash installed on the server that interfaces with an ultrasound machine?

Remote Maintenance

Check the security of the remote maintenance and support connection for the device. Often, rather than sending a device to the vendor for patches, an organization will call the device vendor and have its technical staff remotely connect to the system. Attackers can sometimes exploit these features as backdoors that allow administrative access. Most of these remote connection methods are insecure. Consider the Target breach, where attackers infiltrated the store’s main network via a third-party HVAC company.

Vendors might patch devices remotely because there is usually no good way to have IoT devices in your network patched on time. Because some are sensitive and complex devices, the company staff can’t just surreptitiously start installing patches on them; there’s always a chance of them breaking during the process. And what happens if the device malfunctions while there’s an urgent need to use it (as in the case of a CT scanner at a hospital or a critical temperature sensor in a power plant)?

It’s important to assess not only the remote support software (ideally by reverse engineering its binaries) and its communication channel, but also the established process for remote maintenance. Does the facility use a 24/7 connection? Is there two-factor authentication when the vendor connects? Is there logging?

Filesystem Access Controls

Check 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 crucial directories and files (like service executables), allowing for easy privilege escalation attacks. Do nonadmin users really need to have write access on C:\Program Files? Do any users need to have access to /root? We once assessed an embedded device with more than five different startup scripts that were writeable by nonroot users, allowing an attacker with local access to essentially run their own programs as root and gain complete control of the system.

Data Encryption

Check that sensitive data is encrypted. Begin by identifying the most sensitive data, such as Protected Health Information (PHI) or Personally Identifiable Information (PII). PHI includes any records about health status, provision, or payment of health care, whereas PII is any data that could potentially identify a specific individual. Make sure this data is encrypted at rest by inspecting the system configuration for cryptographic primitives. If someone managed to steal the device’s disk, could they read that data? Is there full-disk encryption, database encryption, or any kind of encryption at rest, and how cryptographically secure is it?

Server Misconfiguration

Misconfigured services can be insecure services. For example, you can still find FTP servers that have guest user access enabled by default, allowing attackers to anonymously connect and read or write to specific folders. We once found an Oracle Enterprise Manager, running as SYSTEM and accessible remotely with default credentials, that allowed attackers to execute operating system commands by abusing stored Java procedures. This vulnerability enabled attackers to completely compromise the system through the network.

Mobile Application and Cloud Testing
Test the security of any mobile application associated with the IoT system. These days, developers often want to create Android and iOS apps for everything, even pacemakers! You can learn more about mobile app security testing in Chapter 14. In addition, consult the OWASP Mobile Top 10 list, Mobile Security Testing Guide, and Mobile Application Security Verification Standard.

In a recent assessment, we discovered that an app sent PHI to the cloud, unbeknownst to the physician or nurse operating the device. Although this isn’t a technical vulnerability, it’s still an important confidentiality violation that stakeholders should know about.

Also, assess the security posture of any cloud component associated with an IoT system. Examine the interaction between the cloud and IoT components. Pay particular attention to the backend APIs and implementations in cloud platforms, including but not limited to AWS, Azure, and Google Cloud Platform. You’ll commonly find Insecure Direct Object References (IDOR) vulnerabilities, which allow anyone who knows the right URL to access sensitive data. For example, AWS sometimes lets an attacker access S3 buckets using the URL associated with the data objects the bucket contains.

Many of the tasks involved in cloud testing will overlap with mobile and web app assessments. In the former case, the reason is that the client using these APIs is usually an Android or iOS app. In the latter case, the reason is that many cloud components are basically web services. You could also inspect any remote maintenance and support connections to the cloud, as mentioned in “Host Configuration Review” on page 50.

We’ve encountered a range of cloud-related vulnerabilities hardcoded cloud tokens, API keys found embedded in mobile apps and firmware binaries, a lack of TLS-certificate pinning, and the exposure of intranet services (such as an unauthenticated Redis caching server or the metadata service) to the public due to misconfigurations. Be aware that you need permission from the cloud services’ owner to perform any cloud testing.

Conclusion

Several of us have served in the military’s cyber defense departments. There we learned that doing due diligence is one of the most important aspects of information security. Following a security testing methodology is important to avoid neglecting some obvious cases. It’s easy to miss low-hanging fruit simply because they seem too simple or obvious.

 outlined a testing methodology for performing security assessments of IoT systems. We walked through passive reconnaissance, and then described and broke down the physical, network, web application, host, mobile application, and cloud layers into smaller segments.

Note that the conceptual layers covered  are in no way absolute; there’s often a lot of overlap between two or more layers. For example, a battery exhaustion attack could be part of an assessment of the physical layer, because the battery is hardware. But it could also be part of the network layer, because an attacker could conduct the attack through the component’s wireless network protocol. The list of components to assess isn’t exhaustive, either, which is why we refer you to additional resources when applicable.