Chapter 14: Hacking IoT and OT

Wow, what a world we live in. The past few years have seen an explosion in devices connecting us to the internet. It's important to understand these Internet of Things (IoT) and Operational Technology (OT) devices, what they can do, and why security is so important to us with these devices. Seriously – we need to grasp this technology. Don't believe me? Ask the casino in Las Vegas that got hacked via a thermostat… on a fish tank! (https://mashable.com/article/casino-smart-thermometer-hacked)

In this chapter, we'll cover the following topics:

• Understanding IoT
• IoT hacking
• Methods used for IoT
• OT and methods used to hack it

So, let's start by understanding IoT.

Understanding IoT

You must be thinking – Dale, Internet of Things, is it that big of a deal? I mean, isn't it just mostly in homes? Well, it's in more places than you might think. What we're starting to see, and why it's such an issue for us, is that we're seeing it in things such as Heating, Ventilation, and Air Conditioning (HVAC) systems. The famous Target breach was all handled through an HVAC system. We're seeing it in fire and safety systems, lighting, and transport, and this could include office buildings, retail locations, education, hospitality, airports, and even stadiums.

We're seeing it emerge in the energy sector, such as windmills or turbines, batteries, generators, drills, and other energy-related machines that may be used to switch off electricity or slow it down. We also see it within the consumer and home sector. It just surprises me every day when I see a new device or appliance that has internet access. Again, whether it's gaming systems, alarm systems, speaker systems, or even lights or locks, chances are the device has access to the internet. I didn't even know this, but the dishwasher I purchased can contact the manufacturer for troubleshooting.

We're also seeing this phenomenon show up in the industrial sector. In mining, for example, you can use automation for resources, such as real-time asset tracking, predictive and preventative maintenance, and monitoring, which can detect excessive vibrations or temperature increases and forecast time to failure and what needs to be fixed. There are automation resources for agricultural and irrigation systems. I had an opportunity to work with a local city municipality where I live. We took the water that comes down the mountains and stored it, and we used it for what's called secondary water. It's stored, and then we distribute it throughout the communities and use that water to water our grass so that we're not using our drinking water to water our grass. All of this is controlled through automated valves. Automation helps us with cost-saving, and that's why it's so attractive.

We also have automation making its way inside the security and public safety sector – whether it be surveillance, tracking, or even emergency services. IoT is infiltrating quite fast, and of course, we're also seeing it pop up inside IT and network sectors, both at the public and enterprise levels.

An attacker that can access medical equipment could be a real issue for us. Let's look at an example. My wife happens to work for a large retail electronics store. They are partnering with several medical sector-based companies to provide monitoring for elderly people, either via a monitoring service or their adult children. Automation can provide real-time monitoring for bed pressure sensors, which would let me know if my dad may not be out of bed yet. This would help me figure out if he might be feeling ill. Being able to communicate directly with the elderly is important.

We're observing automation appear within medical implants as well, particularly in terms of modifying them. My son-in-law is about to have hearing surgery. The device they're going to be putting in his ear will allow him to link to baby alarms and smoke detectors so that he can hear them clearly or be notified that something's going on. So, if you weren't aware of all these sectors being affected by IoT, you can see that the landscape for attackers is growing almost daily to attack people – maybe even hourly at this point.

Let's talk more about how IoT works.

How does it all work?

You may be asking yourself – how does IoT work? Well, there are several different components that you need to be familiar with. Let's start with what's referred to as the sensing technology of those nifty little devices. Maybe it's a doorbell or a thermostat. It could even be a valve in an industrial environment that can be turned on or off.

Figure 14.1 – Example of how IoT devices interoperate

These devices then interface with what is referred to as an IoT gateway. These gateways are used to bridge the gap between the IoT devices, as well as the interaction with the end user. Think of them as the middlemen with IoT.

Then, we have the communication channel, which is the internet. Through this communication channel, our gateways typically talk to what we refer to as either the data storage and/or a cloud server.

Here, the data is collected after it goes through the gateway and arrives at the cloud servers. That data is then stored and analyzed. Based on the application itself, that information can be sent to the end users' remote app, which could be on their smart device. So, from an attacker's perspective, you can see that there are a lot of different possibilities, as far as an attack vector is concerned, but we'll talk about that more later in this chapter.

Now, let's talk about the architecture of IoT.

The architecture of IoT

With IoT, there are different layers – or I should say, components – that are involved in the entire IoT environment. The architecture consists of several different layers, as shown in the following diagram:

Figure 14.2 – The IoT architecture is made up of several layers

The first layer is referred to as the edge technology layer. This layer is where all the hardware parts, such as sensors, readers, software sensors, or the physical device itself, as well as radio frequency identification (RFID) tags, could be located. If you think of any of the devices we deploy, these would be at the edge technology layer. These devices are designed to collect information and they're going to send that information back to the cloud servers or the data storage locations.

The next layer is what we refer to as the access gateway layer. This is what bridges the connectivity between the providers on the backend side and our edge technology layer, or our devices.

Next, we have the internet layer, which is extremely important to us because it's how we communicate. Now, depending on the manufacturer, we can have two different endpoints, such as device-to device, device-to-gateway, or even device-to-cloud. This layer is what is utilized.

We also have what's referred to as the middleware layer, which is a two-way communication channel. This layer sits between the application layer and what we refer to as the hardware layer. Its main responsibility concerns data management, handling issues such as data analysis, data aggregation, data management, filtering devices, discovering devices, and even access control, where we can say who has access to these devices via the application.

Then, we have the application layer. This layer within IoT oversees making sure services are delivered to users from different areas geographically and in different departments, to ensure they have access to whatever it is that they need.

That wasn't too bad, was it?

Now, let's talk about the protocols and technology that IoT utilizes.

Protocols and technologies

Let's break these down into some different categories.

Short-range communication

Let's look at some of the short-range communication resources that are available to us.

Z-Wave

Z-Wave is a home automation standard. It allows us to manage things such as our air conditioners, HVAC systems, thermostats, and home theater rooms. We can control everything from door locks to speaker systems in this way.

ZigBee

This is another short-range communication protocol just like Z-Wave. Both these protocols can be considered mesh networks, but the advantage with ZigBee is that if a signal originates from a centralized hub, each device can act as a repeater.

There's an issue with how far the signals can go. With ZigBee, it's limited to about 40 feet. With Z-Wave, we can go up to about 330 feet in an outdoor environment while in an indoor space, it's typically about 100 feet. Now, ZigBee does have the advantage of theoretically connecting to around 65,000 devices, whereas Z-Wave is limited to a mere 232 devices. But one of the bigger downsides, at least for me, is that ZigBee uses the standard 2.4 GHz range, which a lot of our wireless devices are already utilizing, whereas Z-Wave uses the 908.42 MHz frequency. As far as communicating with their devices and controls is concerned, both use the Advanced Encryption Standard (AES) 128 encryption standard. It's a requirement to get certified by Z-Wave.

Wi-Fi

We know all about Wi-Fi, right? The most common standard for Wi-Fi is 802.11n, which gives us a speed of up to about 600 Mbps, with a signal of approximately 150 feet indoors and 300 feet outdoors if unobstructed.

Wi-Fi direct

This acts as peer-to-peer communication between devices. Here, one device acts as the access point, while the other one acts as the client.

Radio Frequency Identification (RFID)

RFID is extremely popular with those little tags that you see everywhere, where you can set your phone on the tag, and it'll look up the product that tag represents. On the attacking side, we love creating RFIDs that look like they're designed to do something, but they do something completely different. We're starting to see RFID tags being used in pets, as well as livestock, and even cars and pharmaceuticals.

Bluetooth smart or Bluetooth low energy (LE)

This is just Bluetooth technology, but it's designed to create a Local Area Network (LAN) or a personal network.

Light fidelity or Li-Fi

It sounds like Wi-Fi, right? It's very similar to Wi-Fi, but it does have two major differences. One is speed (at 224 Gbps), while the other is that it uses Visible Light Communications (VLC) (yeah, I know what some of you are thinking– isn't that a media player? All these acronyms we must keep track of), but basically, we're using light for communication.

Near-field communication (NFC)

This uses a magnetic field to communicate between two electronic devices. So, for example, when you purchase something with Apple Pay or any type of mobile payment method where you set your phone down, that typically uses NFC technology.

Quick response (QR) codes

QR codes are those square-looking barcodes most of us have seen. They allow you to store a little bit more information than regular barcodes, but both are going to contain information about the product itself or other products they may be attached to.

Now, let's talk about mid-range communication.

Midrange communications

Let's look at a couple of solutions we should all be aware of since they assist us with midrange communication.

HaLow

HaLow operates in frequency bands that are just below the 1 GHz range, which means it can transmit about twice as far as standard Wi-Fi, and it utilizes the 900 MHz band on the Wi-Fi channel. The 900 MHz band is unique because it handles going through walls or solid structures a little bit better. It doesn't require a true line of sight.

LTE-Advanced

This is a standard mobile communications frequency that's utilized. It provides an enhancement to the standard LTE, which means it gives us a higher capacity in terms of how fast data is transmitted, as well as how far it can be transmitted. This helps us as far as performance is concerned.

Long-range communication

Let's discuss some of the long-range communication resources we can use.

Low-powered wide-area networks (LPWANs)

As its name suggests, this is done through a low power, which is great, but it's been designed to provide a long-range communication channel between two endpoints.

Low-powered wide-area networks (LoRaWANs)

This is typically used in industrial machine-to-machine or secure two-way communication.

SigFox and Neul

SigFox and Neul are very similar to each other and are designed for devices that have very small battery lives. Both work below the 1 GHz bandh, but Neul leverages tiny slices of the TV white space spectrum to deliver highly scalable, high-coverage, low-power, and low-cost effective network switches.

Very Small Aperture Terminal (VSAT)

VSAT is another type of communication protocol that we use to transfer data. We typically see small satellite dishes being utilized for this type of communication

Cellular

Cellular is designed to give us high-quality data, but there's a cost associated with it – it's expensive and has high power consumption.

Now that we have covered the wireless side of things, let's look at the wired side.

Ethernet

Most of us should be familiar with Ethernet. It is used for connecting different devices to a wired LAN. It is the most common type of LAN.

Multimedia over Coax Alliance (MoCA)

We're not referring to the coffee here. This is a technology we can use with existing coax cabling to convert Ethernet signals to run across those coax cabling. Then, you have another converter on the other side that takes it off the coax and puts it back on the Ethernet. I've used a similar device to turn Ethernet into HDMI for longer HDMI runs.

Power-line communication (PLC)

Now, this is a cool one. It runs across our power lines in our home/offices! I know, right? This is where electrical wires are used as data transmission and power sources.

Next, let's discuss some of the available operating systems we can use for IoT.

Operating systems for IoT

In this section, we'll talk about the operating systems that IoT typically uses.

ARM Mbed

Yeah, you can tell it's short for embedded, and no, I didn't misspell it. This is one of the most used low-power device operating systems available. It's typically used in our wearable devices.

Zephyr

Zephyr is an operating system that's used in devices that are low in resources or constrained by resources, as well as low powered.

Ubuntu Core

Ubuntu is also known as Snappy, and we see this used in drones, as well as gateways. These can be found in IoT and robots.

Apache Mynewt

This is an operating system that's designed to run on devices utilizing low-energy Bluetooth protocols.

RIOT

We see this operating system on a lot of actuator boards, sensors, and even embedded systems. Typically, this operating system is extremely quiet, so it's a quiet riot. See what I did there? If you're not familiar, that's a famous 1980s rock, heavy metal band, so again, you can Google that one too, but don't bang your head over finding it. Okay? I won't give up my day job. I'll stick with this book.

Brillo

This is an operating system that's based on Android, and it's considered an embedded operating system. Again, we're going to use this on low-end devices, such as our thermostats.

Real-time operating systems (RTOSs)

These types of operating systems run extremely fast; we're talking milliseconds. The reason we need those types of operating systems is when we have a situation or a scenario where interaction must be spontaneous. For example, when your airbags deploy in your car, you can't wait multiple milliseconds for the bag to deploy to save your life.

Two of the most famous RTOSs include Nucleus and Integrity. The major differences between Nucleus and Integrity are that Nucleus features storage and database management, USB and networking, and multimedia support. It also has some advanced Graphical User Interface (GUI) capabilities, whereas Integrity is designed for more multi-core computers. RTOSs are typically used within military functions, such as the Joint Strike Missile (JSM), which is being developed initially for the Royal Norwegian Airforce. Lockheed Martin is using it in conjunction with the F-35 fighter, where this operating system is running internally on a bomb bay door so that it can open instantaneously as missiles are being launched. Again, when the pilot pushes a button, it needs to happen then, not a couple of seconds from when they push the button.

Zephyr

We identified Zephyr as an operating system previously, but it's also a real-time operating system that can be used on all sorts of devices, whether it's a wearable device, an IoT router, or robotics.

Windows 10/11 IoT

Both Windows 10 and 11 IoT are editions of Windows that run on headless devices (that is, with no keyboard or mouse attached). It's designed to run without a display and offers integration for IoT devices, high security, and updates directly from Microsoft.

Amazon FreeRTOS

This RTOS is small. It's designed for microcontrollers that make small, low-power, edge devices easy to program, deploy, secure, and manage.

Next, let's discuss the challenges IoT presents to us.

The challenges that IoT presents

As you've seen so far, we've got some big issues when it comes to the different attack vectors that can be presented to an attacker regarding IoT. Here are some of the challenges that create a lot of vulnerabilities for us:

• One is the interoperability standards we have, or the lack thereof. There are so many products that come with IoT built into them that no one's following a real standard at this point. Some manufacturers aren't concerned about the security of their devices. Now, this is a problem because several of these manufacturers aren't looking at how their devices are used, especially when it comes to testing their application programming interfaces (APIs) or their inability to secure their devices. So, whether it's from the end user or a third party, a security hole is opened. For example, let's say that my SmartThings (https://www.samsung.com/us/smartthings) hub is interoperable with several different products, but to make that connection, it must issue an API. If that API is utilized and, for example, I've got wireless speakers in my house, if the product is flawed security-wise, an attacker could gain access to the Samsung Hub if they wanted to.
• We also have the issue of – believe it or not – clear text and open ports still being utilized. A lot of these devices are being sold without any encryption techniques being used to transmit data back and forth between either the device and the gateway or between the gateway and the cloud services. This can also happen with open ports because somebody may have forgotten to turn them off. We also have the issue of basic security and privacy issues not being followed. Again, a company that makes refrigerators may not have anybody on staff that's worried about security or privacy.
• We also have the issue of support being available for firmware and operating system updates. Sometimes, it can be difficult to update the firmware. Let's look at an example. I have a little computer on my bike, which I ride almost every day, and it tracks how far I've gone, my altitude, how much I'm climbing, my speed, my heart rate, and even my cadence. Well, this product shocked me quite a bit because I downloaded the application for it and after running the application for a couple of days, I started thinking about the firmware. Well, how do I update the firmware? After doing a little research, I found out that I had to download a separate application to update it, which I wasn't warned about, and I wasn't told that there was a separate app that I should download. Now, remember, we update the firmware in our operating system to patch holes or counter the vulnerabilities in a device, and in some cases, the manufacturer's updates could end up breaking some of the functionality of the device. So, in some cases, we have manufacturers who are refusing to allow firmware or operating system updates because it will stop things from working.
• Finally, we have storage issues. Nowadays, these devices are getting smaller and smaller as far as their physical size is concerned – for example, a water bottle that's going to remind me to drink water every day. There's not a lot of space there for a lot of hardware, so we're not going to have a lot of storage space. However, transmission by that device is virtually limitless, right? What this ends up doing is creating issues for us as far as data storage goes, as well as the management or protection we need to make sure we or manufacturers implement. You may have more data flowing across than you need at a particular time because there's no storage. We've got to get rid of it, right? Again, I'm speaking from the manufacturer's point of view. Yeah, can you believe this is happening? Default or weak credentials are still being used. In some cases, they're hardcoded. Often, the manufacturer doesn't even realize they're there. This is because they buy the operating system or the interface from a third party that they just want to implement within their product line.

So, as you can see, IoT adds some challenges we need to understand and be ready for. Now, let's talk about physical attacks.

Physical issues

Physical attacks on IoT devices include an attacker stealing the device from you, maybe modifying or tampering with it, counterfeiting it, or even injecting malicious code and then placing the device back within your network. That doesn't sound fun.

We also have insecure web interfaces. What we're finding is that a lot of these devices have web interfaces built into them. Any time we talk about a web interface, we know there's got to be a web server supporting it. If it hasn't been patched, it's just getting handled through clear text, or – better yet – it's not even secured, this type of challenge can lead to a vulnerability attack on the device itself.

It's a little computer, so can I do a buffer overflow? Absolutely. And since these devices are subject to buffer overflows, this means they're also subject to SQL injection or some type of an injection attack.

We also have development issues. What I mean by this is that we, as security professionals, have these devices coming into our network infrastructures. Sometimes, because of the complexity of these devices or how they operate, this adds to the complexity of the different policies we must deploy and implement. In some cases, I feel for the people that must create these policies because it's adding a completely new environment to what may be your already secure network, and now we've got IoT to worry about.

We also have an issue with vendor support. The device is only good so long as the vendor is there for you. In some cases, we see the vendors go out of business (especially after they've been breached). If you plan on bringing these devices into your infrastructure, the firmware and the operating systems must be upgradeable. This should be mandatory. If any company or vendor doesn't support you on that, you should look for a completely different solution because you're just asking for a door to be opened for you.

We also have regulatory and rights issues, and this is more of a what can happen issue. Because of all the interconnections of IoT devices, some security issues may come up where no legal law has been defined at this point. Let me give you an example. Let's go back to the example of the casino that was breached via the thermostat of a fish tank. So, who was at fault? Was it the thermostat manufacturer or was it the casino that hooked the IoT device to their internal network instead of a separated network? All these things are challenges for us, but hopefully, the field is going to clear up here soon.

Next, let's talk about the IoT hacking process.

IoT hacking

Let's talk about some of the vulnerabilities and some of the hurdles that IoT presents to us.

The first is what I term data value. This involves capturing data as IoT devices communicate with each other and with the cloud behind them or their cloud providers, which increases the risk because it makes IoT more obscure. Time after time, we're starting to see where the IoT environment is allowing attackers to access other devices, as well as networks they may be connected to. So, many companies deploy their IoT environments on their production network, which kind of makes me sad and sick inside.

Another issue is data aggregation. Again, we have a lot of devices here speaking with other resources that may be outside of our control.

There's also something that's referred to as sensor fusion, which is the ability to combine information from two completely disconnected sensing devices to create more complex information or a view of the environment the attacker is going after. Let me give you an example. In Boston, the city created an app that would identify potholes in the city's roads using mobile phones, accelerometers, and GPS data. This information was sent to the Public Works Department to help them find out where the worst potholes were. But if you think about it from an attacker's point of view, if I'm able to gain access to that environment, couldn't the attacker use this application or its information to possibly divert the city services away from the areas that need the most attention?

We also have the issue of integration. Now, you may be thinking, that's great – integration, right? We typically look at that as a positive thing. But when we start allowing these devices that aren't very secure onto our existing networks and integrate them into applications that we need to be developing internally, or even into other IoT apps, we should be a bit concerned.

This is a huge issue in that the healthcare industry is being inundated with hundreds and hundreds of different devices that are based on IoT environments. Imagine the complexity of thousands, if not hundreds of thousands, of these devices being deployed, and you need to make sure that a specific pump is given the right commands to update the dosage. We also need to make sure that only the physicians or the care practitioners have the authority to do so, and that nobody can hack it.

The culprits

First, it's going to be the application, right? The application can create problems by having no security updates allowing default passwords that are in place or even passwords or backdoors that can't be changed.

We also have the mobility issue and the fact that we have various communication channels. Are they encrypted? Are we using authentication? Do we lack the ability for proper storage security, even if someone's using an insecure API?

We also have the cloud. Again, maybe our authentication hasn't been set up correctly with their cloud providers, or maybe there's no encryption for storage or communication to the cloud. Then, there's the web interface for the application that's hosted on the cloud environment, and then we have the network itself. Are the services running that are supposed to be running, and have they been locked down and secured? Do we have any updates being pushed out to our devices either manually, automatically, or through a third-party application? Do you even have a firewall in place for your IoT environment? Again, the best practices here are to have your IoT environment on a completely segmented network, and just like any network, you need to make sure you have the same type of security devices in place. Remember, when we introduce the cloud, we're introducing a whole new infrastructure.

Device memory challenges

Let's talk about the massive attack surface, and when I mean massive, it is really big, folks – device memory. We're talking about how much space there is for the device to operate. Let's talk about some of the things that are possibly being stored in the device's memory.

Encryption keys? Yeah, absolutely. How about credentials from third-party vendors? Yup, and even the possibility of cleartext credentials being stored.

We also have ecosystem access controls; this means any of the components that are integrated within our IoT environment. Let's say we have trusts or different types of trusts between components. For example, Samsung, by default, with their SmartThings hub, automatically trust all their components – whether it's a water sensor, motion sensor, or location sensor – so these types of implicit type trusts can be a vulnerability for us. Also, there is the aspect of enrolling a device in your environment.

Let me give you an example. When I hooked up my Samsung SmartThings hub, I was shocked and amazed at how easily it worked – all I had to do was turn the motion sensors on and it automatically picked up several devices. So, not having any type of authentication taking place could allow for a malicious device to come on board.

Well, what do we do? We need to have some way of decommissioning those types of devices, such as clearing the data or even just resetting the device to the factory default to make sure there's nothing left in the device's memory or storage.

We also have a physical interface. The physical interface could include both a user command-line interface (CLI), as well as an administrative CLI. Again, if we give an individual user access to the device and they have administrative rights on that device, that would be a great pivot point for me to get onto their network from an attacker's perspective, as well as the ability to go through a privileged escalation scenario. Does the device have a physical port, such as a USB port? Does it support universal Plug and Play? What happens when you plug in a Rubber Ducky? If you're not familiar with a Rubber Ducky, it's a USB thumb drive, but the system picks it up as a keyboard, which means I can type in all kinds of fun commands. When looking at IoT devices, one of the things you should look at is whether the vendors support a way of disabling these types of ports or different services that may be available on that device.

The other attack surface would be the web interface itself. Just like anything else, when there's a web interface involved, we've got issues that could occur, such as some type of an injection attack or a cross-site scripting attack, or even a cross-site request forgery attack. In some cases, I might be able to do some type of username or user account enumeration.

Now, let's talk about the various IoT attacks.

Types of IoT attacks

With all the various types of IoT that are out there, we need to be aware of some of the potential types of attacks that can occur with IoT devices.

DDoS attacks

This is where an attacker turns all your IoT devices into evil little devices that can perform DDoS attacks or make them a member of a bigger botnet.

Rolling code attacks

Most IoT devices operate on a rolling code. This is like the keyless entry system for your car or garage door opener, where you must press the buttons in the right order before it will open. The attacker forces you into pairing with their device by making you try lots of codes one after another until they find the right one that opens your door. Theoretically, it should be impossible because the attacker makes a device with a matching key fob and your controller doesn't allow more than one device with a particular key to operate in your area. But most devices don't make their rolling codes truly random.

BlueBorne attacks

BlueBorne is less of a specific IoT attack and more about IoT devices communicating using Bluetooth, which Android and Linux have supported by default since 2012. Android has had a patch available since September 2017 when this was made public knowledge. But as we've discussed, many products won't get patched, even when the manufacturer knows about it, because they can't afford to build another device at their price points. I think they should be illegal in most cases.

Sybil attacks

Imagine someone creating dozens of fake devices, such as baby monitors or lightbulbs, all with different MAC addresses. They use these fake devices to communicate with your real device and learn about your network. Then, they use the real identity of one device against you by taking over that device to discover things about your network.

Jamming attacks

This has nothing to do with toast, jam, and a knife. This is when someone broadcasts at the same frequency as your device and confuses it or causes it to not work at all.

Hacking a smart grid with a backdoor

This is where your electric company has a device on your home network that allows them to turn appliances on and off remotely. So, say that cybersecurity researchers found a backdoor in many of these devices that allowed them to turn your appliances on and off. Yeah, that wouldn't cause an issue at, say, a hospital, right?

SDR-based attacks

Software-defined radios (SDRs) present a new challenge for IoT infrastructures. SDR is the method with which radio-frequency hardware is controlled with software. This can be used for good or bad, depending on who it's being used by. SDRs are devices that can understand how to send and receive different frequencies within the radio spectrum. Attacks can be attempted at both the full-duplex (two-way communication) and half-duplex (one-way transmission) modes.

You can also use DNS rebinding to alter some DNS entries on the target's router or gateway and then talk to those devices through their web interface using the default password. Crazy huh?

Now, let's about the methods that are used for IoT.

Methods used for IoT

The methods attackers use will normally follow a certain methodology. These methods can be broken down into sections we'll discuss next. Let's take a look.

Reconnaissance

Most IoT devices are endpoints participating in an IP network. Network reconnaissance is the process of gathering information about these networks and systems. When we talk about IoT, this pertains to scanning for common vulnerabilities such as default passwords or hardcoded secret keys that may be publicly available. Most attackers will use specialized tools such as Metasploit or Shodan to find these targets. And depending on the type of network, a variety of tools can be used.

Shodan is crazy amazing as an information-gathering tool. This search engine can find all kinds of devices, including web servers, routers, printers, IP cameras, and more. It's common to find default passwords on devices such as wireless access points (WAPs) or IP cameras. All this information is valuable for the hacker to use later for exploitation (for example, taking advantage of a weak password).

As an example, to search on Shodan for webcams on a certain street, you must enter webcamxp city:"GothamCity" (or your target city), which would show you publicly visible webcams in your city. Want to find Google web servers? Type in Server: gws" hostname:"google". Or do you want to see something scary? How about password 1234? Yep, this gives you a list of devices that are using a password of 1234. Crazy, huh?

If you want lots of information, head over to the FCC's website (The Federal Communications Commission in the United States) at https://www.fcc.gov/oet/ea/fccid (see Figure 14.3 and Figure 14.4). This is an organization where all devices that are distributed or manufactured in the USA must register their devices. There's a plethora of intel here.

Figure 14.3 – FCC website

As shown in the following screenshot, it can provide a lot of great information:

Figure 14.4 – Detailed PDF documents on an item from FCC

If you're looking for an actual application, check out MultiPing (https://www.multiping.com) or even IoTSeeker (https://github.com/rapid7/IoTSeeker), which will scan your devices and tell you whether they are still using the default passwords.

Figure 14.5 – Sample results after using an IoT seeker application

Another common approach that's used by attackers (in conjunction with network reconnaissance) is to try to tie together information that's been gathered from the device's web interface with what they know about Linux/Unix systems. Header meta-information in HTTP transactions, for example, often includes software version numbers and other clues that can reveal where vulnerabilities exist within implementations of common protocols.

Once attackers have some idea of how the IoT device operates internally, it's much easier for them to find vulnerabilities in its code. This is where scanning comes into play.

Vulnerability scanning

Once the attacker has found a list of potential targets, they will start vulnerability scanning. This entails using well-known exploits that may be available for public consumption that target specific vulnerabilities in the IoT device's software or firmware. Often, these exploits come from third-party research groups (Google Project Zero and others) who will identify and release security holes in all kinds of devices, or from vendors who may not disclose these types of vulnerabilities to their customers. Another great place to check out for vulnerability information is the United States Computer Emergency Readiness Team (US-CERT), as they often post advisories about recently identified flaws that may affect IoT devices.

Many of these vulnerabilities are based on known implementations, bugs, or design flaws within the protocol, which are necessary to understand before you can identify potential targets. This becomes easier as the list of protocols the device supports increases over time, as well as its ability to process what's being sent by an attacker.

Launching attacks

Once the attackers have identified a known vulnerability, they will begin penetration testing efforts by exploiting that specific vulnerability within the IoT device's particular operational environment. We can't stress enough how important conducting this type of activity in a lab environment is!

Gaining and maintaining remote access

This is where the IoT researcher (that's you!) will apply specific exploits against a particular vulnerability they have discovered. Then, the attacker can run a series of tests to determine whether a device has been successfully compromised and how it was done, as well as what user-level access is available after entering the system.

After remote access has been achieved, the attacker has several ways to infiltrate and exfiltrate data from an IoT device. This can include uploading and executing scripts on the IoT device to gain persistence, establishing a remote shell for later use, or even moving laterally within devices that are connected to compromise other devices on the network.

Once the attacker has gained access to the device, they employ various methods to maintain and extend access. Attackers remain hidden by deleting logs, upgrading firmware, and employing malicious applications such as backdoors, trojans, and other malware to stay on board. To exploit firmware, attackers utilize tools such as Firmware Mod Kit or Firmwalker, to name a few.

Speaking of firmware, firmware is a set of instructions that tells the hardware how to function. Firmware analysis is the process of examining the firmware of a target loT device to identify its underlying flaws and risks. Attackers use firmware analysis to find passwords, API tokens, endpoints, vulnerable services running, backdoor accounts, and configuration files that are being used. With time and patience, attackers can reverse engineer the firmware and discover weaknesses and backdoors that present themselves as a means to maintain future access. Attackers don't always need to maintain all these capabilities; instead, they should be prepared for multiple contingencies by having other specialized tools at hand. For example, using malware such as Mirai or BASHLITE will maintain access for future use if or when the attackers wish to commandeer the device again.

Now, let's look at some ways in which we can protect our IoT devices.

Countermeasures to protect IoT devices

There is no one threat that we can correctly protect against since there are many different kinds, and each has a way of attacking and exploiting IoT devices. Combining everything would be too cumbersome and costly for most IoT users, but IoT device manufacturers are in a unique position to implement IoT security by design.

However, we have some steps we can take to protect the network. Let's take a look:

1. Disable any guest or demo accounts.
2. Utilize any auto lockout features for invalid login attempts.
3. Use strong authentication mechanisms.
4. Place your control systems and devices behind firewalls.
5. Isolate the IoT network away from your business network.
6. Protect IoT devices from physical access.
7. Disable Telnet.
8. Use end-to-end encryption and public key infrastructure (PKI).
9. Deploy IPS and IDS devices.
10. And you know this one – update, update, update.

Now, let's discuss operational technology.

OT and methods used to hack it

Operational technology (OT) is a term that's used to describe a variety of technologies that work together as an integrated or homogeneous system in today's modern society. Telecommunications, for example, makes extensive use of OT to move data from the electrical grid to the wheeling station. The same communications are also utilized for financial transactions between electrical consumers and producers. OT is a network of hardware and software that is used to monitor, manage, and control industrial process assets. It's critical to grasp the fundamental principles of OT before attempting to hack it.

The Purdue model

At this point, it's a great time to talk briefly about the Purdue model. The Purdue model is derived from the Purdue Enterprise Reference Architecture (PERA) model, which is widely used to describe the internal connections and dependencies of essential components in the ICS networks. It consists of three zones: the manufacturing zone (OT) and the enterprise zone (IT), which are separated by a demilitarized zone (DMZ).

The Purdue model can be used for analyzing, designing, and securing ICS networks. It can help identify potential security risks and vulnerabilities and provide guidance on how to mitigate them.

In this model, the manufacturing zone (OT) is the most critical part of the network as it includes all field devices that are responsible for process control and automation. The enterprise zone (IT) is less critical as it only provides data storage, connectivity, and other business functions. The DMZ is used to separate the manufacturing and enterprise zones, and it usually contains security devices such as firewalls and intrusion detection systems (IDSs).

We'll cover various OT topics in greater detail later in this chapter.

Let's start by answering the question, what is OT? OT, or an industrial control system (ICS), refers to a specialized system of computerized hardware and software that is dedicated to managing and monitoring physical equipment. ICSs, including Supervisory Control and Data Acquisition (SCADA), Remote Terminal Units (RTUs), Programmable Logic Controllers (PLCs), Distributed Control Systems (DCSs), and other specialized network systems that help monitor and manage industrial operations are part of this technology.

Figure 14.6 – The components of OT

Now, let's look at OT and the security challenges we must deal with.

OT and security – a dilemma

ICSs can monitor and control infrastructures such as electrical grids, oil pipelines, networks of elevated transit stations, and more, but these systems have a fundamental security disadvantage – they were built to monitor and control, not necessarily to protect.

This inaccuracy arises from the fact that OTs have limited access to information about what is going on inside complex infrastructures. For example, an OT control system for a manufacturing plant may provide information on the water levels in tanks, but it usually lacks access to information on water temperature or pH, which are critical parameters for the optimal operation of chemical processes.

Hacking OT – a threat to critical infrastructure

Contrary to popular belief, the systems that control infrastructures such as electrical grids, oil refineries, dams, and more are not secure. Since the sophistication of OT networks has increased, hackers have also had to increase their sophistication by learning more about the OTs they are targeting. The bad news is that it takes much less knowledge and skill to hack an OT system than, say, a traditional IT system.

The success of a hack is determined by two critical factors – the vulnerability of the targeted system and the ability of the hackers to exploit that weakness. In recent years, numerous vulnerabilities have been discovered in ICSs by security researchers who have published their findings at security conferences such as Black Hat, DEFCON, CanSecWest, and others. Some of these vulnerabilities have made it easy for experienced hackers to penetrate IT networks and control OT systems.

Should we combine IT and OT?

IT/OT integration can help a company's performance by reducing gaps between the two domains. The convergence of IT and OT is more than just about using technologies; it's also about personnel and processes. Traditional IT/OT teams are generally kept apart, with IT staff in one department and OT workers in another. For example, IT teams keep track of internal processes such as programming, system updates, and network security. OT teams, on the other hand, are responsible for ensuring that everything runs smoothly both internally and externally. Both IT/OT teams must be familiar with each other's operations and organizational structure. This does not imply that IT experts must be converted into field or plant personnel; it simply implies connecting them so that they may collaborate to enhance security, efficiency, quality, and productivity.

Challenges of OT risks

As I mentioned previously, most OT systems are still running on old versions of software and using antiquated hardware, making them susceptible to harmful exploits such as phishing, espionage, ransomware assaults, and other types of attacks. These sorts of assaults may be highly damaging to products and services.

To prevent these vulnerabilities from being exploited, here are some of the risks that OT presents to us:

• Physical and environmental disasters: This is one of the most well-known risks in the OT environment. An example would be a hurricane or tornado that can damage equipment and facilities.
• Intentional attacks: Acts of terrorism, sabotage, and espionage could result in considerable damage to both property and people.
• Malicious programs such as viruses and malware: These are some of the most common attacks that occur in OT environments. Viruses and malware can quickly spread, affecting various equipment throughout a plant.
• Social engineering: This entails the use of human-centric attack methods to gain access to OT systems. Examples include phishing or spammy emails being sent to employees who are tricked into giving up their passwords.
• Network complexity: OT systems use different technologies from IT, so there is a need for a clear separation of the network. However, additional entry points to networks can prove to be a security risk.
• Lack of visibility: OT networks are not monitored properly, so threats go undetected. This can lead to a cascading effect of threats that may affect many people and equipment.
• Poor security management: OT systems have weak security defenses, which makes them vulnerable to cyberattacks.
• Outdated systems: A lack of updates and patches can leave OT systems open to danger.
• Convergence with IT: As I mentioned earlier, convergence between IT and OT teams enables them to work together. However, this is not an easy task; it requires considerable effort for both sides to learn about each other's roles and how they can contribute to their respective domains.
• Vulnerable protocols: Protocol stacks are the foundation for all network traffic. Open and broken protocols can enable attackers to take control of OT systems.
• Security by obscurity: This refers to when manufacturers don't share knowledge about their products with others, including competitors. When this occurs, it becomes easier for hackers to find their way into these devices.
• Lack of training: OT personnel and teams do not get the relevant training to secure their systems. As a result, they put company equipment and data at risk.
• Lack of security standards: There are currently no security standards for OT devices; this means that every developer may implement their own defense mechanisms. Unfortunately, such measures often lack proper testing and validation, leaving vulnerabilities that can be exploited.

Next, we'll discuss ICSs.

Introduction to industrial control systems (ICSs)

ICSs are used to control industrial processes. They're computer systems that monitor and control the operations of equipment such as compressors, pumps, generators, motors, reactors, boilers, furnaces, ovens, turbines, conveyors, and more. These components are what make up an ICS environment:

• Supervisory Control and Data Acquisition (SCADA): These are control systems that can monitor and control equipment via the ICS environment.
• Distributed Control System (DCS): These are more advanced versions of SCADA that utilize distributed computing.
• Programmable Logic Controller (PLC): These are small computers that work with discrete (discontinuous) signals. They can monitor and control equipment, process data, and more.
• Human-Machine Interface (HMI): This is also known as a man-machine interface. It's used to obtain feedback from equipment, sensors, and more. If an HMI is being monitored by the ICS environment for any abnormalities or problems, it may send out alerts to other personnel via email, text message, and so on.
• Business process control system (BPCS): These systems utilize specialized software and hardware that can monitor and control industrial processes. BPCSs may be used to run the entire ICS environment or just a single component of it, such as a PLC or DCS.
• Safety Instrumented System (SIS): These are software programs that control the flow of (typically hazardous) materials in industrial processes. If they detect any issues, they can send out alerts to other personnel via email, text message, and more.
• Industrial Explosive Device (IED): These are explosive devices that are used to deal with hazardous materials. They're usually part of the SIS's functionality.

Through the ICS environment, operators can monitor their equipment and processes anywhere in the world. However, this environment may be targeted by cyber attacks if it's not properly secured. It would be wise to practice good network security within such an environment because it controls important components that may pose a threat to people and property.

Let's discuss some of the different operation modes of ICS.

Operation modes of ICS

ICS systems can be configured to run in three different modes:

• Open-loop: In open-loop control, there is no feedback from the environment. Consider a temperature sensor placed in an oven. The oven's computer will turn on or off until it reaches the desired temperature that has been set by either a human operator or a program.
• Closed-loop: In closed-loop control, there is feedback from the environment. Now, let's take our oven scenario again. The temperature sensor will inform the computer to turn on or off accordingly until it reaches the desired set point.
• Manual-moop: In manual-loop control, there is feedback from the environment, but the control loop is under human supervision. This system won't turn on or off until a human operator intervenes in its operations.

Next, we'll discuss the potential risks and threats associated with ICS.

ICS risks and threats

Unfortunately, ICSs are vulnerable to cyber attacks. The following are several known risks and threats associated with ICS:

• ICS systems are susceptible to several network-related attacks (for example, network sniffing and spoofing). Attacks such as these can be launched to intercept sensitive information, modify data, and more.
• ICS systems are susceptible to malware attacks (for example, viruses and worms). Malware can cause physical damage to equipment and data loss, among other things. Merely looking at malware with the wrong type of equipment can cause it to go off.
• ICS systems are susceptible to ransomware attacks. These are malicious software programs that are used to encrypt ICS data until a ransom is paid in return for an encryption key.
• Attackers can use social engineering methods against personnel to gain access to ICS environments. For example, they can call up personnel pretending to be from a trusted company sending official-looking emails.
• ICS systems are susceptible to Denial of Service (DOS) attacks. These are used to cripple ICS environments by flooding computers with useless data designed to overwhelm their resources so that they're unable to perform their normal operations.
• ICS systems are susceptible to Trojan attacks. Trojans are used to gain backdoor access to computers. Like malware, they're capable of causing physical damage.
• ICS system components can be hacked to perform malicious acts. For example, a PLC or DCS could be hacked to cause process shutdowns or other issues within the ICS environment.
• ICS systems are susceptible to several client-side attacks (for example, cross-site scripting and cross-site request forgery). Attacks such as these can be launched against clients so hackers can gain access to the system using the victims' permission.

Now, let's look at port use when utilizing ICS/SCADA systems.

The ports that are used by ICS/SCADA systems

ICSs that are used in SCADA and other critical infrastructure systems typically use seven-port communications protocols to connect end devices:

• Port 80: HTTP (used for communications between ICS/SCADA clients and servers)
• Port 88: UDP (used for communications between ISC/SCADA components for status updates, device naming, and more)
• Port 21: FTP (used to transfer files between ICS/SCADA components)
• Port 25: SMTP (used for sending emails)
• Port 23: Telnet (used to connect to remote devices to configure them or check their status)
• Port 161: SNMP (used for network management and configuring devices over IP networks)
• Port 443: HTTPS (used for encrypted communications between ICS/SCADA components)

Now, let's discuss some of the attacks that ICS/SCADA may encounter.

Attacks on ICS/SCADA

ICS/SCADA has vulnerabilities regarding being attacked. Here are some of the potential attacks that may be used against ICS/SCADA:

• HMI-based attacks: HMI-based attacks target human-machine interfaces, which are used to view and manipulate data on ICS/SCADA systems. These types of attacks can be launched by gaining unauthorized access to the network or tricking operators into visiting spoofed websites that launch malware onto their computers.
• Memory corruption: A memory corruption attack is a hack that aims to corrupt the memory of an ICS/SCADA component so that it fails to perform as expected. These types of attacks can be launched by gaining unauthorized access to the network or intercepting communication between components to tamper with them.
• Credential management: These aim to gain access to an ICS/SCADA environment by using default passwords. This would also include the lack of encryption as data is in motion, which would reveal cleartext passwords and account names.
• Code injection: These types of attacks inject malicious code into ICS/SCADA software to cause technical issues, disrupt operations, or allow attackers to access the system. The vulnerabilities in this category include common code injections such as SQL, operating system, command, and some domain-specific injections. Gamma script, like many other domain-specific languages for HMIs, is vulnerable to code injection attacks.

Now, let's discuss some of the specifics of side-channel attacks.

Side-channel attacks

These types of attacks target the physical implementation of cryptosystems (for example, anything that processes cryptography). They exploit unintentional characteristics of the physical implementation that leak information about cryptographic keys or other sensitive data.

Power analysis can be used to derive information about cryptographic keys by observing details such as the amount of time it takes for computations to occur, or by measuring electromagnetic emanations from integrated circuits.

Timing analysis is another side-channel attack that's considered high-throughput, which allows attackers to perform it fast enough to be effective in most cases. Timing analysis can be used with ICS/SCADA systems because they typically run on embedded devices with RTOS. A loop approach is used by attackers to recover these passwords. They attempt one character at a time until they find the first one that works, and then they repeat for additional characters if the first was correct. If not, the loop ends. By monitoring how long it takes a device to complete one whole password authentication process, attackers can figure out how many characters that have been entered are correct.

How can you defend against OT hacking?

The best way to defend against OT hacking is with awareness and periodic audits, such as red-teaming exercises. Awareness can be achieved through regular training programs; audits should include testers who look for vulnerabilities in the network and digital filesystems of the devices. Such audits also consider what could happen if a system were hacked: how many devices could be impacted and how quickly would the business become aware of the threat?

Here is a list of some options to consider when you're trying to defend against OT hacking:

• To lower current risk exposure, conduct a risk assessment regularly.
• Use purpose-built sensors to discover the vulnerabilities in the network inactively.
• By combining threat intelligence with asset protection, you can detect threats and prioritize OT patches.
• Make sure your OT devices and software are always up to date.
• Unused ports and services should be disabled.
• For OT applications, use best security practices and secure coding.
• Continuously monitoring and detecting log data that's been generated by OT systems is required to discover real-time assaults.
• Raise security awareness among staff and provide them with up-to-date security measures.
• Use hashing to create strong and secure passwords and change the factory-preset passwords.
• Use two-factor authentication, VPNs, encryption, firewalls, and more to provide secure remote access through a variety of barriers.

So, as you can see, IoT has its challenges and those challenges will increase as more and more devices are brought into the world of IoT.

Summary

In this chapter, we discussed IoT and OT. In a time when so many products are being developed with some smart aspect to them, there is a challenge of balancing functionality with security. Unfortunately, the security aspect seems to be a second thought and that presents a new host of potential security vulnerabilities. We addressed what IoT is, some ways to hack IoT, and some methods attackers can use on IoT. Finally, we discussed the role OT also plays in the security challenges of IoT.

In the next chapter, we'll discuss cloud computing.

Questions

As we conclude, here is a list of questions for you to test your knowledge regarding this chapter's material. You will find the answers in the Assessments section of the Appendix:

1. Which of the following is responsible for message routing and identification in an IoT architecture?
   1. The middleware layer
   2. The edge technology layer
   3. The access gateway layer
   4. The internet layer
2. When is the Shodan search engine most likely to be employed in the IoT hacking methodology?
   1. Information gathering
   2. Vulnerability scanning
   3. Gaining access
   4. Launching attacks
3. Which of the following countermeasures are effective in preventing IoT hacking? (Select all that apply.)
   1. Enabling lockout features for excessive login attempts
   2. Disabling guest and demo accounts
   3. Enabling UPnP
   4. Disabling telnet
4. Of the tools listed, which is the best choice for quickly discovering the IP addresses of IoT devices on your network?
   1. MultiPing
   2. IoTInspector
   3. beSTORM
   4. Z-Wave Sniffer