To kill an error is as good a service as, and sometimes even better than, the establishing of a new truth or fact.

—Charles Darwin

Most threat actors don’t want to work any harder than they absolutely have to. Unless they are specifically targeting your organization, cutting off the usual means of exploitation is often sufficient to encourage them to move on to lower hanging fruit elsewhere. Fortunately, we know a lot about the mistakes that many organizations make in securing their systems, because, sadly, we see the same issues time and again. Before we delve into common flaws on specific types of platforms, here are some that are applicable to most, if not all, systems:

•   Missing patches/updates   A system could be missing patches or updates for numerous reasons. If the reason is legitimate (for example, an industrial control system cannot be taken offline), then this vulnerability should be noted, tracked, and mitigated using an alternate control.

•   Misconfigured firewall rules   Whether or not a device has its own firewall, the ability to reach it across the network, which should be restricted by firewalls or other means of segmentation, is oftentimes lacking.

•   Weak passwords   Even when default passwords are changed, it is not uncommon for users to choose weak passwords if they are allowed to do so. Our personal favorite was an edge firewall that was deployed for an exercise by a highly skilled team of security operators. The team, however, failed to follow its own checklist and was so focused on hardening other devices that it forgot to change the default password on the edge firewall.

Access Points

Perhaps the most commonly vulnerable network infrastructure components are the wireless access points (WAPs). Particularly in environments where employees can bring (and connect) their own devices, it is challenging to strike the right balance between security and functionality. It bears pointing out that the Wired Equivalent Privacy (WEP) protocol has been known to be insecure since at least 2004 and has no place in our networks. (Believe it or not, we still see them in smaller organizations.) For best results, use the Wi-Fi Protected Access 2 (WPA2) protocol.

Even if your WAPs are secured (both electronically and physically), anybody can connect a rogue WAP or any other device to your network unless you take steps to prevent this from happening. The IEEE 802.1X standard provides port-based Network Access Control (NAC) for both wired and wireless devices. With 802.1X, any client wishing to connect to the network must first authenticate itself. With that authentication, you can provide very granular access controls and even require the endpoint to satisfy requirements for patches/upgrades.

Virtual Private Networks

Virtual private networks (VPNs) connect two or more devices that are physically part of separate networks and enable them to exchange data as if they were connected to the same LAN. These virtual networks are encapsulated within the other networks in a manner that segregates the traffic in the VPN from that in the underlying network. This is accomplished using a variety of protocols, including the Internet Protocol Security (IPSec) Layer 2 Tunneling Protocol (L2TP), Transport Layer Security (TLS), and the Datagram Transport Layer Security (DTLS) used by many Cisco devices. These protocols and their implementations are, for the most part, fairly secure.

The main vulnerability in VPNs lies in what they potentially allow us to do: connect untrusted, unpatched, and perhaps even infected hosts to our networks. The first risk comes from which devices are allowed to connect. Some organizations require that VPN client software be installed only on organizationally owned and managed devices. If this is not the case and any user can connect any device, provided they have access credentials, then the risk of exposure increases significantly.

Another problem, which may be mitigated for official devices but not so much for personal ones, is the patch/update state of the device. If we do a great job at developing secure architectures but then let unpatched devices connect to them, we are providing adversaries a convenient way to render many of our controls moot. The best practice for mitigating this risk is to implement a Network Access Control (NAC) solution that actively checks the device for patches, updates, and any required other parameter before allowing it to join the network. Many NAC solutions enable administrators to place noncompliant devices in a “guest” network so they can download the necessary patches/updates and eventually be allowed in.

Finally, with devices that have been “away” for a while and show back up on our networks via VPN, you have no way of knowing whether they are compromised. Even if they don’t spread malware or get used as pivot points for deeper penetration into your systems, any data these devices acquire would be subject to monitoring by unauthorized third parties. Similarly, any data originating in such a compromised host is inherently untrustworthy.

Mobile Devices

Smartphones and mobile technologies have overtaken any other form of computing in terms of its accessibility. There’s no question that these devices and the applications that run on them have become a fixture in most people’s daily routine. The integration of mobile technologies into nearly every aspect of life means that these devices have a far greater density of stored personal information that any other media in history. The ability to interact with service providers that have traditionally operated in a strictly brick-and-mortar sense, such as financial service and health service providers, demonstrates the increasing criticality of these devices. Additionally, improvements in infrastructure, distributed systems performance, and high-speed communications have enabled service providers to offer their services reliably. But as mobile technologies and platforms evolve, there are an accompanying set of vulnerabilities targeting these systems, devices, and apps connected to the mobile ecosystem.

Given the potential for impactful and persistent access, it’s no wonder that mobile devices have become a lucrative target for malicious programmers. We’ll describe the spectrum of mobile vulnerabilities and threat vectors using three categories: network, device, and application.

Network Vulnerabilities

We can look at mobile network vulnerabilities from two angles: flaws of the telecommunications backbone that the device relies on, and flaws of the device’s communications interface to these networks. An example of the first kind was brought to light as early as 2008 and again throughout the next decade related to the Signaling System No. 7 (SS7) protocols. SS7 is a set of protocols that enable large communications networks to exchange the information needed to pass calls and texts seamlessly and to ensure correct delivery to the user and correct billing information to the carrier. If you travel to a foreign country, for example, SS7 allows your calls to be transparently forwarded without the need for additional action from you. However, if given access to these exchange points, actors can record or listen in on calls, read SMS messages sent between phones, and collect location data of the communicating parties. While the likelihood of gaining that access is extremely low, it’s not out of the question, especially for sophisticated and well-resourced actors.

The Heartbleed Bug is an example of the second kind of mobile network vulnerability that we’ll cover. Heartbleed was a serious vulnerability in the popular OpenSSL cryptographic library and was disclosed in 2014. It impacted the security and privacy of a wide number of apps and services, such as web, e-mail, and messaging platforms, as well as connected devices such as VOIP phones, routers, and network-attached storage (NAS). The bug’s name is derived from the flaw of the OpenSSL heartbeat function, which helps keep network connections alive by exchanging data periodically between the client and server. As explained by researchers from Codenomicon and Google, the flaw could enable an attacker to recover up to 64K of data, which could include session cookies, passwords, and cryptographic private keys of the communicating parties. Filed as CVE-2014-0160, it was believed to have impacted almost 20 percent of web servers around the world.

Device Vulnerabilities

Device vulnerabilities can be devastating, because a successful exploitation means that the device’s entire functionality, contents, and associated personal user data are often at risk. For many years, researchers theorized of an attack on device memory involving the manipulation of the electrical charges that are responsible for keeping the memory elements of a device in state—that is, on or off. The challenge with these types of attacks is that they exploit fundamental properties in the operation of the device, so patching is difficult if not impossible.

When a processor accesses dynamic random-access memory (DRAM), it will attempt to read an element, or bit, of memory that is held in state by an electric charge. These small charges are sent to the memory elements to encode data in 1’s and 0’s. For performance reasons, DRAM will access the state of a memory bit by reading the whole row, modifying a bit, and replacing the contents of the row. Occasionally, this operation will cause charges to leak and make changes to neighboring bits, causing them to change their state. These routine and random occurrences are addressed through various correction mechanisms, but if an attacker can intentionally force this charge spillage in a predictable way, he may be able to cause specific changes to bit states that have an upstream affect to the software in use. This is exactly what attackers hope to achieve using the Rowhammer technique. By repeatedly accessing the adjacent rows of a target row—the row immediately above and the row immediately below, as shown in Figure 5-1—the attacker may cause a specific bit flip to change in the target row with all the “hammering.”

Figure 5-1 Depiction of Rowhammer attack

This bit change may be exactly what’s necessary to initiate a cascading effect, which eventually grants an attacker access to a resource he previously did hot have. Fortunately, an attack like Rowhammer is exceedingly rare and difficult to execute; nevertheless, it demonstrates the relative difficulty in defending against attacks of this kind.

Operating System Vulnerabilities

Operating system makers regularly publish system and firmware updates that include improvements to operating system functionality and security. An interesting phenomenon occurs after these bulletins are released. As with most software security notifications, the authors hope that adoption can be as complete and rapid as possible, while attackers hope to maximize the window of vulnerability, or the amount of time they have to exploit these recently disclosed flaws. For a variety of reasons, Android devices typically have longer vulnerability windows than iOS systems. This is primarily because of the challenge of coordinating multiple manufacturers and carriers to develop an operating system patch for Android devices. Figure 5-2 shows a chart of Android distribution worldwide, according the Google Developers portal. Though version 10 is the latest major release as of the writing of this book, it doesn’t have nearly the adoption rate as the four previous versions.

Figure 5-2 Android version adoption (May 2019)

In contrast, iOS versions see rapid adoption and no fragmentation, in part because of the existence of a centrally controlled ecosystem. Figure 5-3 shows the latest iOS version as of the writing of this book, iOS 13, as the clear dominant shareholder for iOS installs across all devices. According to the Apple App Store, iOS 13 accounts for 77 percent of the active install base, iOS 12 accounts for around 17 percent, and previous versions account for 6 percent.

Figure 5-3 iOS version adoption (January 2020)

App Vulnerabilities

While security engineers and architects work tirelessly to improve core security protocols, user security and privacy issues regularly occur at the app level, where data is often collected and stored for the first time. Even while security controls around data in transit and at rest improve, when a human enters or reads personal data, malicious actors routinely take advantage of the opportunity.

Apps experience increasingly short development cycles as creators hope to ship their products as quickly as possible to the end user. Unfortunately, this often means that security concerns are second to functionality. We’ll cover this larger concept of secure software development in depth in later Chapter 9, but with quick software development cycles come vulnerabilities. Of the top ten risks to mobile platforms identified by the Open Web Application Security Project (OWASP) in its 2016 list, eight of them are directly related to applications. We’ll discuss some of these categories and their potential for impact in the following sections.

Improper Platform Usage

In addition to building in technical controls to prevent abuse, platform creators publish documentation that is designed to be consistent and well understood. Despite this, some developers take shortcuts that introduce vulnerabilities that may allow attackers to circumvent existing controls. Although not all of this behavior is intentional, occasionally security researchers will discover developer behaviors that blatantly contradict the best practices recommended by platform guidelines or that are obviously designed to circumvent security controls. In these cases, the developers’ digital code-signing signatures may be revoked, or they may be banned from the platform altogether.

Many developers attempt to do the right thing, but sometimes they may allow in errors related to how the app interfaces with the platform. This may occur in the form of incorrectly crafted API calls or incorrect implementation of built-in security controls.

Insecure Data Storage

Vulnerabilities related to data storage often have as much impact on privacy as they do on security. Such vulnerabilities usually occur when developers fail to handle data transfer and storage in a manner that protects confidentiality and integrity. World readable files, improper logging, and surreptitiously collected analytics data fall into this group.

Insecure Authentication

Authentication mechanisms can be difficult to implement, and sometime developers may not fully grasp all the requirements for correct implementation of these mechanisms. There are a few ways that applications may be vulnerable from insecure authentication. First, there is the unfortunately common occurrence of locally stored passwords and secrets without the use of built-in security systems, such as iCloud Keychain. Authenticating a user locally often introduces the possibility of bypassing an authentication routine completely, especially on jailbroken or rooted devices. Second, an app may not sufficiently enforce password policies, allowing for weak passwords to be entered into a system. Although this doesn’t have immediate impact, it nonetheless introduces a vulnerability that may be exploited at a later point.

Insecure Authorization

As with authentication vulnerabilities, authorization vulnerabilities may allow for access to resources on a mobile platform that an actor would not otherwise have. The main difference, of course, is that authorization vulnerabilities affect the mechanism that ensures that a user gains access to the correct resource, rather than verifying that the user is who he claims to be. Mitigating these types of vulnerabilities involves verifying that the roles and permissions associated with a user are correct and appropriate, and that they are verified using only back-end systems that are not accessible by the user. Sometimes authorization vulnerabilities are also authentication vulnerabilities, such as the case of a resource request in which the authentication occurs out of order—for example, if an API request occurs and is somehow fulfilled before any validation occurs.

Code Quality Vulnerabilities

To this day, some code practices are technically legal, but they still introduce the possibility for issues such as buffer overflow vulnerabilities. Code-level mistakes continue to be an issue, especially when older code is reused. Sometimes, when the only solution is to completely rewrite a major portion of the app to remove a flaw, some developers simply will not do so.

When executed, code runs within an environment that the original developer is not in control of, so the possibility of modification after the fact is real. Attackers will often attempt to make binary changes directly to the application package or its core dependences. Additionally, developers are more reliant on third-party libraries and frameworks, which themselves may be subject to targeting and compromise.

One of the best ways to prevent vulnerabilities of this kind is via manual secure code review using subject matter experts. Although this may be laborious, it helps security teams understand what the app is trying to do before it’s executed. Furthermore, an app should be written so that it is able detect at runtime any code that may have been manipulated. The app must be able to react appropriately to ensure integrity and to prevent malicious actors from injecting functionality into otherwise trusted code.

Internet of Things

The Internet of Things (IoT), the broad term for Internet-connected nontraditional computing devices, is expanding rapidly in terms of adoption. IoT devices, which include televisions and fridges, now offer features not usually associated with them—or, in some cases, needed by their users. Nevertheless, they are here to stay, so we must contend with the security implications they introduce. For the enterprise, the most common IoT devices are those responsible for adding efficiencies to the daily operations of an organization while lowering cost, since these specialized devices reduce the requirement of having dedicated computer systems to perform the same functionality. Your physical security team, for example, may rely on a network of closed-circuit television cameras to monitor the organization’s property. The facilities team may use smart thermostats and lighting, which will adjust their operations based on sensors designed to detect occupancy. More and more, printer companies are adding functionality not only to access print services from the desktop network, but to allow for the printer to send messages to administrators in the case of low ink and paper.

For the security analyst, it’s important to understand the massive impact these devices may have on increasing an organization’s attack surface. As organizations put more faith in these connected devices to give us visibility over their assets, they must take extra care to protect their networks and maintain the confidentiality, integrity, and availability of the data that flows through them. As mentioned several times throughout this book, your understanding what devices are connected is the beginning of your understanding how best to protect the organization.

Patching, as you know, is a necessary part of the vulnerability management process. Some devices, while Internet-connected, do not have straightforward mechanisms to update their software. In many cases, users may have to download updates manually and then interface directly with the device to apply the change. These additional steps are costly, especially if the IoT footprint is hundreds or thousands of devices, and they often lead to administrators deprioritizing maintenance of these devices, which results in them running outdated software, and thus being more vulnerable to exploit.

Manufacturers often release connected devices that contain default, static, or easily decipherable passwords. When we combine this with the fact that many of them ship with services open to remote access, these devices are a target for attackers running automated scripts for bulk exploitation. Several times in the last decade, IoT devices with default passwords and services in place have been targeted, exploited, and used in massive botnets. After they’re initially accessed, attackers upload malicious code and maintain connectivity with them to form large clusters of centrally controlled devices capable of performing distributed denial-of-service (DDoS) attacks, data theft, and large-scale spamming, as shown in Figure 5-4.

Figure 5-4 Typical botnet structure

The Mirai Botnet

Mirai is a malware strain that infects IoT devices and was behind one of the largest and most effective botnets in recent history. The Mirai botnet took down major websites via massive DDoS attacks against several sites and service providers using hundreds of thousands of compromised IoT devices. In October 2016, a Mirai attack targeted the popular DNS provider Dyn, which provided name resolution to many popular websites such as Airbnb, Amazon, GitHub, HBO, Netflix, PayPal, Reddit, and Twitter. After taking down Dyn, Mirai left millions of users unable to access these sites for hours.

Embedded Systems

Embedded systems are characterized by lightweight software running specialized tasks on low-power microprocessors. These instructions are written to the device’s firmware, or they are hardwired instructions, which govern every aspect of the device’s operation and interface with the rest of the world. Despite the firmware being written using standard programming languages, these programs often pose a special challenge to monitor for and remediate vulnerabilities given the way the programs are executed on the hardware.

Real-Time Operating Systems

A real-time operating system (RTOS) is a crucial underlying technology of many high-performance, specialized, connected devices. It is an operating system designed to provide low-latency responses on input. Usually found in vehicle electronics, manufacturing hardware, and aircraft electronics, RTOS solutions excel at scheduling tasks to avoid any possibility for delays in processing or delivery. The vulnerabilities that affect RTOS are not unique, but the vast deployment of RTOS technology in high-performance devices makes them especially important.

There’s no greater example than the recent disclosure of vulnerabilities affecting VxWorks, one of the most popular RTOS implementations in the world. In 2019, Armis Labs discovered and published details on 11 zero-day vulnerabilities in VxWorks that allowed for complete control of affected devices. These devices ranged from medical equipment, such as MRI scanners, to elevator controllers. The vulnerabilities stemmed from IPnet, VxWorks’ TCP/IP stack implementation. As a result of the severity and potential for impact of the vulnerabilities, named URGENT/11, the US Food and Drug Administration (FDA) issued a warning about the potential for an attacker to “remotely take control of the medical device and change its function, cause denial of service, or cause information leaks or logical flaws, which may prevent device function.” The unusual nature of the FDA’s involvement highlights not only the increasing dependency on connected technology from organizations of all kinds, but also the importance of federal agencies, manufacturers, and security researchers in working together to identify, communicate, and prevent abuse of vulnerabilities when they are discovered.

System on a Chip

A system on a chip (SoC) is the integration of software and hardware onto a single integrated circuit and a processor. Similar to microcontrollers in terms of their minimalist approach to tackling special tasks, SoCs usually involve more complicated circuitry. The integration of all the necessary functions offers multiple advantages related to cost and power consumption, but this tight integration means a higher likelihood for system-wide impact in the case of an exploit. There are also considerations of trusted hardware when it comes to SoC that do not necessarily apply to traditional operating systems. (We’ll discuss the concept of trusted hardware more in Chapter 6.) Because the software and hardware are so tightly coupled with SoC solutions, it’s critical to ensure that hardware verification is performed alongside any software vulnerability assessments.

Field Programmable Gate Array

Specialized chips often offer increased performance and savings at the cost of device flexibility. One possible solution to the inflexibility of integrated circuit functionality is the use of a field-programmable gate array (FPGA). A FPGA is a kind of programmable chip that is widely used in many areas, including automotive electronics, medical devices, and consumer electronics. The design of FPGAs enables programmers to reconfigure the hardware itself to accommodate new software functionality.

The range of vulnerabilities to FPGAs is fairly broad and includes those that apply to both hardware and software. Like other hardware, systems based on FPGAs remain vulnerable to flaws found in higher level protocols used in the system’s operations, along with the challenges of proper implementation. Additionally, FPGAs are a target for very specialized attacks that rely on compromising the device functionality at the level it’s written. FPGAs use a hardware description language (HDL) to define the operation of the chip. Should an actor manage to gain access to the HDL process, it would be possible for him to introduce malware, which might be extremely difficult to detect in upstream operations.

Common Vulnerabilities and Exposures (CVEs) are occasionally issued for vulnerabilities related to FPGAs in commercial products. CVE-2019-1700, for example, describes a vulnerability related to the FPGA used in a series of Cisco firewall devices. In this case, the FPGA vulnerability could allow for an attacker to cause a denial-of-service (DoS) condition by taking advantage of a logic error in the FPGA implementation. Because of the way the FPGA processes certain packets, an attacker could initiate the condition from an adjacent subnet by sending a series of specially crafted packets to the device for processing. The resulting queue wedge condition would cause the device to stop processing subsequent packets.

Physical Access Control

Physical access control systems usually rely on a combination of hardware and logical artifacts to make a determination about physical access for a user presenting the credentials. Radiofrequency identification (RFID) badges and readers are among the most common types of physical access control. Every complicated system has vulnerabilities up and down the stack. With physical access control systems, attackers often rely on taking advantage of one or more flaws somewhere between the hardware and presentation layers to gain access to decision systems.

First, it’s often possible for an attacker to acquire a hardware reader and perform a teardown to determine whether any mechanical or electrical flaws exist. If, for example, there is logic performed on the device between the RFID card and the reader that simply results in a 50ms 5-volt pulse from the device reader to the door mechanism, then gaining access could be as simple as removing the reader from the wall and creating that pulse using another tool. This is an extremely simplified way to remind you of the point that physical systems are vulnerable to physical vulnerabilities and physical attacks.

One of the more publicized vulnerabilities of physical access systems is their susceptibility to spoofing attacks by way of replay or cloning. Replay is a method of capturing and emulating the signals exchanged between legitimate components of a physical access control system. Early systems were particularly vulnerable to attacks in which threat actors captured the radio signals emitted from a card and replayed them at a later point to the reader device to gain access. Many of these methods have since been defeated using encryption and the use of unique client/server exchanges. Cloning is a method of capturing the information from a card and emulating its functionality, or copying it to a similar device.

Connected Vehicles

For organizations in the automotive sector, or those that use a massive fleet of connected vehicles, the vulnerabilities associated with connected cars are high priorities in their security strategy. Threat modeling realistic attack vectors and attacker methodologies will absolutely be part of their vulnerability assessment plans. The key questions that these organizations will hope to answer are as follows:

•   What kinds of vulnerabilities most commonly affect a modern connected car?

•   What vectors are attacks likely to use to compromise a vehicle?

•   How can we mitigate these vulnerabilities?

•   How do we prioritize our resources to address these challenges?

Most times, when there is a discussion about a vulnerability related to a vehicle, it’s in the context of some kind of tethered, or physically connected, compromise. However, with the emergence of connected vehicles, this can no longer be the assumption for security professionals, anyone working in the automotive industry, or even the general public.

Imagine for a moment that a security system is installed on a vehicle’s computer system. Suppose an attack that gains access to the vehicle’s communication and control systems to wreak havoc is indistinguishable from the system’s normal operation. But even if a detection system did alert you to the malicious behavior that intended to create an immediately hazardous situation in the vehicle, the system’s priority would unquestionably be to preserve life first, and then react to the alert. An attacker trying to cause chaos on such a system would probably be less concerned about being detected and more interested in making sure the attack was successful.

CAN Bus

The Controller Area Network (CAN bus) vehicle standard defines the ways in which independent components of vehicles control systems, usually in the form of electronic control units (ECUs), communicate with one another without having a central controller. The primary security issues with the CAN bus standard lie in the fact that, as a low-level protocol developed in the 1980s, it includes no inherent security features to protect the signals that are transmitted across the network. As a result, mechanisms that work to maintain the security of the data are applied often at the component level, with no measures for consistency. Signals that pass along the CAN bus are also not protected by encryption by default, so the chance of a man-in-the-middle attack is far greater than an attack on other systems with protection. A typical CAN bus configuration is shown in Figure 5-5.

Figure 5-5 A typical CAN bus configuration

A few years ago, security researchers Charlie Miller and Chris Valasek presented a demonstration of a vehicle takeover initiated from the vehicle’s Uconnect cellular connection. After gaining access to the vehicle’s network via a flaw in the Uconnect system, the two pivoted to take advantage of a vulnerability in the vehicle’s entertainment system. After replacing the radio unit’s functionality with their own, they were able to send commands through the car’s CAN bus to its physical components, including the engine and the wheels. Both Miller and Valasek worked closely with the car’s manufacturer to ensure that all aspects of their research would be correctly addressed, in a great example of responsible disclosure. Their research advanced the public discussion about connected devices and even helped move forward legislation regarding connected vehicles.

Drones

Hobby and professional quadcopters, often called drones, are at their core flying robots capable of a wide range of activities. Photographers and government organizations take advantage of the unique access and perspective that these small and maneuverable devices offer when taking photos or performing inspections. Drone platforms have seen rapid adoption, in part because of the plummeting cost of the hardware, and also because of improvements in the user interface and integration with other familiar technologies such as smartphones and tablets.

Drones are, however, a growing concern for the law enforcement, physical security, and aviation communities because of their potential use as tools of disruptive and dangerous activities. (The forced grounding of hundreds of flights at Gatwick Airport in December 2018, for example, occurred following reports of drone sightings close to the runway.) Many of those expressing concern are also concerned about drone use in low-cost surveillance, enabling controllers to capture high-quality audio and video at a fraction of the cost of higher end tools. Furthermore, skilled operators can modify these drones to perform signals collection, tracking, and identification functionality in much the same way that some intelligence organizations might.

From a security point of view, regardless of the intent of the user behind the controls, we must remember that attackers often use vulnerabilities to take over and abuse the legitimate access of well-meaning users on the network. It’s no different with drones—a malicious actor may take advantage of vulnerabilities in the drone’s communication systems, its hardware, or the manufacturer’s web portal to steal information, perform surveillance, or cause disruption.

Hardware Security

As we’ve stated throughout the book, physical access is often the best kind of access from an adversary’s perspective. Many low-cost drones use easy-to-find components, standard storage media, and common connectors. If your organization uses drones for monitoring or inspection purposes, their security begins with preventing the devices from getting into the wrong hands to begin with. Recovering media and photos from these devices often just involves removing the storage media and connecting it to another computer.

Communications Channels Security

In the interest of cost savings and ease of use, early drones often operated as Wi-Fi hotspots that users would connect to via a mobile phone or tablet to control the device. In many cases, these hotspots were not protected by any kind of password or encryption. The security community quickly discovered this problem, along with the fact that some drones, such as those in the popular Parrot AR line, left many network services such as telnet wide open, as shown in Figure 5-6.

Figure 5-6 nmap scan results of probe performed on Parrot AR.Drone 2.0

Additionally, many of these devices are susceptible to DoS attacks via Wi-Fi; an attacker could overload the drone with at a high volume of connection requests until its hardware is overwhelmed and subsequently shuts down. The result would almost certainly involve damage to the drone and whatever is below it at the time.

Drone manufacturers have since improved drone security following early lessons of shipping the devices without any kind of protection against hijacks and disruptions via the drone’s communications channels. Although modern drones are far more resilient to these kinds of attacks, researchers are constantly working to discover new vulnerabilities and improve the security of these devices.

Web Portal Security

In late 2018, a security research team from Check Point Software Technologies, an Israeli security software and appliance company, demonstrated the grave effects that could result from a drone web portal takeover. The researchers were able to determine that drone vendor DJI’s website login process contained a vulnerability that allowed anyone to authenticate to any account without legitimate credentials. Leveraging the vulnerability, team members were able to log into a target account and gain access to the DJI FlightHub, the web-based app that gives users complete awareness and management over their drones. The researchers worked with DJI to patch the issue quickly, but their research illustrates a successful exploit via vector that might be completely out of control of the user. This dependency on third parties has to be considered when developing your security strategy.

Industrial Control Systems

Industrial control systems (ICS) are cyber-physical systems that enable specialized software to control their physical behaviors. For example, ICSs are used in automated automobile assembly lines, building elevators, and even HVAC systems. A typical ICS architecture is shown in Figure 5-7. At the bottom layer (level 0), are the actual physical devices such as sensors and actuators that control physical processes. These are connected to remote terminal units (RTUs) or programmable logic controllers (PLCs), which translate physical effects to binary data, and vice versa. These RTUs and PLCs at level 1 are, in turn, connected to database servers and human–machine interaction (HMI) controllers and terminals at level 2. These three lower levels of the architecture are known as the operational technology (OT) network. The OT network was traditionally isolated from the IT network that inhabits levels 3 and 4 of the architecture. For a variety of functional and business reasons, this gap between OT (levels 0 through 2) and IT (levels 3 and 4) is now frequently bridged, providing access to physical processes from anywhere on the Internet.

Figure 5-7 Simple industrial control system

Much of the software that runs an ICS is burned into the firmware of devices such as programmable logic controllers (PLCs), such as those that run the uranium enrichment centrifuges targeted by the Stuxnet worm in 2010. This is a source of vulnerabilities because updating the ICS software cannot normally be done automatically or even centrally. The patching and updating, which is pretty infrequent to begin with, typically requires that the device be brought offline and manually updated by a qualified technician. Between the costs and efforts involved and the effects of interrupting business processes, it should not come as a surprise to learn that many ICS components are never updated or patched. To make matters worse, vendors are notorious for not providing patches at all, even when vulnerabilities are discovered and made public. In its “2016 ICS Vulnerability Trend Report,” FireEye Cybersecurity described how 516 of the 1552 known ICS vulnerabilities had no patches available.

Another common vulnerability in ICSs is the password. Unlike previous mentions of this issue in this chapter, the issue here is not the users choosing weak passwords, but the manufacturer of the ICS device setting a trivial password in the firmware, documenting it so all users (and perhaps abusers) know what it is, and sometimes making it difficult if not impossible to change. In many documented cases, these passwords are stored in plaintext. Manufacturers are getting better at dealing with these issues, but many devices still have unchangeable passwords controlling critical physical systems around the world.

SCADA Devices

A supervisory control and data acquisition (SCADA) system is a specific type of ICS characterized by its ability to monitor and control devices throughout large geographic regions. Whereas an ICS typically controls physical processes and devices in one building or a small campus, a SCADA system is used for pipelines and transmission lines covering hundreds or thousands of miles. SCADA is most commonly associated with energy (for example, petroleum or power) and utility (for example, water or sewer) applications. The general architecture of a SCADA system is depicted in Figure 5-8.

Figure 5-8 Typical architecture of a SCADA system

SCADA systems introduce two more types of common vulnerabilities in addition to those normally found in ICS. The first of these is induced by the long-distance communications links. For many years, most organizations using SCADA systems relied on the relative obscurity of the communications protocols and radio frequencies involved to provide a degree (or at least an illusion) of security. In one of the first cases of attacks against SCADA systems, an Australian man apparently seeking revenge in 2001 connected a rogue radio transceiver to a remote terminal unit (RTU) and intentionally caused millions of gallons of sewage to spill into local parks and rivers. Though these wireless systems have mostly been modernized and hardened, they still present potential vulnerabilities.

The second weakness, particular to a SCADA system, is its reliance on isolated and unattended facilities. These remote stations provide attackers with an opportunity to gain physical access to system components. Though many of these stations are now protected by cameras and alarm systems, their remoteness makes responding significantly slower compared to that of most other information systems.

Modbus

Like CAN bus, the Modbus system was developed to prioritize functionality over security. A communications system created in the late 1970s by Modicon, now Schneider Electric, Modbus enables communications among SCADA devices quickly and easily. Since its inception, Modbus has quickly become the de facto standard for communications between programmable logic controllers (PLCs). But as security was not built in, Modbus offers little protection against attacks. An attacker residing on the network can simply collect traffic using a tool like Wireshark, find a target device, and issue commands directly to the device.

Process Automation Systems

Process automation systems (PASs), which are sometimes called workflow automation systems (WASs), are technologies used by organizations to automate their day-to-day business processes. They help increase efficiency and accuracy in functions that are well established and don’t have too many weird edge cases. For example, when new employees are hired, specific applications need to be provisioned, usually with different permissions, depending on their work roles. Many organizations handle this by running a script or tool that accurately takes care of this in seconds instead of relying on a systems administrator to manually configure each account. PAS/WAS technologies are used in virtually all sectors, from automating the processing of sales orders to controlling assembly line robots or even the flow of electricity through a power grid in SCADA systems.

But problems can arise when the processes and workflows that get automated are complex, subject to edge conditions, or just poorly understood. For example, in 2012 a financial services firm called Knight Capital Group unintentionally bought $7 billion worth of stocks in one hour due to a flaw in its automated trading software, a mistake that nearly ended the company. Threat actors can deliberately exploit vulnerabilities in a PAS, as was the case in the attack on the Bangladesh Bank in 2016 that resulted in the theft of $81 million. These attackers exploited the automated workflows used by the Society for Worldwide Interbank Financial Telecommunication (SWIFT) systems. These examples show the importance of thoroughly testing PASs and protecting them as we would any other system.

Chapter Review

Your ability to protect specialized technologies begins with understanding the roles they play in the organization, mapping their attack surfaces, and identifying likely attack vectors. Security vulnerabilities in specialized technologies include many of the same vulnerabilities that affect technology at large, including failures to adequately define system data sensitivities, insufficient security measures against common attacks, poor implementation of appropriate authentication and authorization systems, and lack of mitigation that adheres to the defense-in-depth concept. Sometimes, however, there are special considerations beyond those for standard servers and endpoints. Trusted hardware becomes much more of a concern when you’re dealing with highly customized systems that work in sensitive spaces, for example. Security teams must also consider the effect that a successful exploitation of any system dealing with a physical dimension may have. Whether it is allowing physical access to an area or controlling vehicles or heavy equipment, the impact of a security event may have effects that extend into the real world.

Questions

1.   Which of these wireless protocols is considered insecure and should be avoided?

A.   RADIUS

B.   WEP

C.   WPA2

D.   ICS

2.   World readable files, improper logging, and surreptitiously collecting analytics data are examples of what kind of vulnerability?

A.   Insecure authorization

B.   Insecure authentication

C.   Insecure data storage

D.   Replay vulnerability

3.   Which communications standard defines the ways in which independent components of vehicles control systems?

A.   CAN bus

B.   Modbus

C.   SS7

D.   RCE

4.   Of the following, which is a type of specialized system whose design is optimized for high-speed, low-latency processing of live data?

A.   FPGA

B.   SoC

C.   RFID

D.   RTOS

5.   Which of the following is not among the challenges with dealing with IoT devices on your network?

A.   Increased attack surface

B.   Difficulties of patching

C.   Static credentials

D.   Difficulties of integration

6.   What is a reason that patching and updating occur so infrequently with ICS and SCADA devices?

A.   These devices control critical and costly systems that require constant uptime.

B.   These devices are not connected to networks, so they do not need to be updated.

C.   These devices do not use common operating systems, so they cannot be updated.

D.   These devices control systems, such as HVAC systems, that do not need security updates.

7.   When describing RFID attacks, which of the following best describes the act of capturing signals between card and reader, and emulating those signals at a later point using specialized hardware?

A.   Replay attack

B.   Brute-force attack

C.   Spoofing attack

D.   Man-in-the-middle attack

8.   The distributed computational power and network access provided by a collection of infected and hijacked IoT devices can be used to perform distributed denial-of-service attacks. This collection of infected and hijacked devices is referred to as what?

A.   SoC

B.   Parallel computer

C.   Botnet

D.   SCADA

Answers

1.   B. Introduced in the late 1990s, the Wired Equivalent Privacy (WEP) is a security algorithm for 802.11 wireless networks. It’s known to be susceptible to attacks that can reveal keys in a matter of minutes.

2.   C. Insecure data storage occurs when developers fail to handle data transfer and storage in a manner than protects confidentiality and integrity.

3.   A. The Controller Area Network (CAN bus) standard defines the ways in which independent components of vehicles control systems, usually in the form of electronic control units (ECUs), communicate with each other without having a central controller.

4.   D. Often found in vehicle and manufacturing electronics, a real-time operating system (RTOS) is a crucial underlying technology of many high-performance, specialized connected devices. It is an operating system designed to provide low-latency responses on input.

5.   D. Difficulties of integration are not a challenge with dealing with Internet of Things devices. IoT is the broad term for Internet-connected nontraditional computing devices that add significantly to an organization’s attack surface. Many of these devices ship with default or static credentials and may be difficult to update.

6.   A. The cost involved and potential negative effects of interrupting business and industrial processes often dissuade device managers from updating and patching these systems.

7.   A. In a Replay attack, valid communications transmissions are captured and retransmitted, often to impersonate a legitimate user to gain access to a system or steal information.

8.   C. Botnets are large clusters of centrally controlled devices capable of performing distributed denial-of-service (DDoS) attacks, data theft, and large-scale spamming. Attackers will often upload malicious code and maintain connectivity with various IoT devices to form botnets.