146. ICS Protocols and Vulnerabilities (OBJ 3.5)
In this lesson, we’re going to talk about the different industrial control system protocols that you may come across in your position as a cyber security practitioner. These protocols include the controller area networks, or CAN, the Modbus, the data distribution service, or DDS, and the safety instrumented system, or SIS. First, let’s consider the controller area network, or CAN. Now the controller area network is a serial network that’s designed to allow communications between embedded programmable logic controllers. Most notably, a CAN is going to be used within vehicles to interconnect the different systems within a car or truck. These days, cars are getting smarter and smarter. For example, there are cars like Tesla that can even drive themself by using sensors located all around the car and passing that information back to a centralized computer. Then the car makes decisions based on that data, and it can adjust the steering or speed of the vehicle for you automatically. These systems and sensors are all located on different subsystems, which focus on different functions.
But they’re all usually interconnected using controller area networks. These controller area networks are not limited to automobiles, though. For example, a typical commercial airliner has miles and miles of cabling that connects different systems involved in flying that plane, as well as keeping the passengers comfortable during that flight, and making sure everything’s working the way it should. This network on the plane is also a type of controller area network. Now with a car-based CAN, a user can actually connect to that controller area network by using the OBD-II port, which is the on-board diagnostics module version two port. Now, ever since the 1990s, every car manufactured for retail sale has to have an OBD-II port available for the end user to access. The reason for this was an on-board computer in these cars were becoming more and more common, and end users and mechanics need a way to be able to send and receive data to inform those on-board computers to be able to get information about what’s wrong with the car. And so the OBD-II port was used for that purpose. Originally, this port was designed just for troubleshooting the on-board computer and the sensors by plugging in a diagnostic tool into the OBD-II port and receiving a specialized code that tells you what is currently wrong with the vehicle. But these days, you can find OBD-II ports being used for a lot of other peripherals as well. Now the controller area network bus will operate much like an ethernet network, and the fact that it’s going to assume that anyone connected to that CAN bus must be a trusted person because they’re located within the vehicle.
Now the CAN bus is also a contentious-based network, just like ethernet is. And this means the devices are going to send data, and if there’s a collision, they will simply resend that data. Now both of these features of CAN buses were used by the initial designers because they never imagined that we’d be using the CAN bus for the types of automation and autonomous driving that we’re attempting to use them for today. So security wasn’t really a big concern back then. Now, if the CAN is completely isolated like they were back in the 80s and 90s, this is pretty safe for us to use with this type of assumed trust. But the problem is, that today, a lot of our modern vehicles are simply not isolated. This is because many of our vehicles now have cellular modems built into them, Wi-Fi built into them, and other network connections allowing communications to and from that vehicle. Therefore, we now have the outside world connecting into our vehicles, and this can actually bring with it a lot of vulnerabilities. Essentially, our cars have now become a part of the internet of things due to all these interconnections that are being made. Unfortunately, though, CAN buses do not have a concept of source addressing or message authentication within the CAN bus due to that legacy development decisions that we talked about that came from the 1980s and 1990s. This means that any message that goes into that CAN bus is immediately considered trusted by the vehicle’s computer. So let’s imagine that I connected a device to your OBD-II port and I injected a message to the CAN bus that tells the car to set its speed at 100 miles per hour. What do you think is going to happen? Well, the car is going to immediately trust that message as factual, and it’s going to then accelerate your car to 100 miles per hour without questioning the legitimacy of that message that was injected because this is how CAN buses were initially designed to work. Now a great example of this can be found in an article from a couple of years ago, written by Andy Greenberg who’s a journalist for WIRED magazine. He reported on his experience while driving a Jeep down the highway at 70 miles per hour, just outside of Downtown St. Louis, when hackers decided to start doing an exploit and injecting messages into the CAN bus of that Jeep. Now, luckily, Andy was doing this as part of an experiment, and the hackers were actually pen testers. But let me tell you what Andy said about the experience. “Though I hadn’t touched the dashboard, the vents in the Jeep Cherokee started blasting cold air at the maximum setting, chilling the sweat on my back through the in-seat climate control system.
Next, the radio switched on to a local hip hop station and began blaring Skee-Lo at top volume. I spun the control knob left and hit the power button, to no avail. Then the windshield wipers turned on, and the wiper fluid blurred the glass.” Now Andy continues in the article to describe all the things that pen testers were able to do as he was driving this vehicle 70 miles an hour down the highway, and they were able to hack into it and do all this stuff remotely by injecting messages directly into the CAN bus through a connection they had set up to the OBD-II port. Now if you’re interested in seeing this article and the joy ride that Andy had in his Jeep, you can go online and watch this video and actually see Andy’s experience during that penetration test. It’s a pretty interesting thing to look at. It gives you a good idea of the kind of vulnerabilities that can be exploited using a CAN bus-based system. So how can an attacker get into a vehicle and attack it? Well, first they have to gain access to the CAN bus. And there’s really three ways you could do that. First, they can connect to the OBD-II port and inject messages into the CAN bus locally. Now you might think that means the attacker has to be sitting in the car with you, but that’s not the case. Just like in the WIRED article I mentioned, an attacker can actually create a small device that plugs into the OBD-II port, and this will give them remote access. Now most OBD-II ports are located underneath the dashboard where nobody can see it visibly unless you’re really looking for it. And so you can just hide this device and then remotely connect to it using a cellular signal or something like that. For example, let’s say you went to eat at a local restaurant and you handed your car off to the valet. While you’re enjoying your meal, that valet plugged in an exploit device into your OBD-II port, and now he has a connection that he can use to inject messages directly into your CAN bus.
The second type of exploit we have actually involves exploiting the CAN bus over the on-board cellular modem in your vehicle that was installed by your manufacturer. If your car has a cellular modem built into it, like a Tesla does, for example, that means you have a connection to the outside world, and therefore the outside world might have a connection back to you. To combat this threat, most vehicles have two networks inside of them, an entertainment network and a vehicular CAN bus. Now these should be segmented both logically and physically to ensure that your vehicle and its occupants are safe for malicious attack. For example, I personally drive a Tesla Model Y, and it has built-in cellular modem that’s used to provide video and audio streaming to the on-board entertainment system. This is one system, and it controls the entertainment functions that requires a connection to the outside world, things like YouTube, and Netflix, Pandora, and Spotify. Then there’s a second system that’s used to control the actual driving of the car. These two systems are not interconnected, and they are logically separated to prevent an attacker from hacking into the driving system of the car while it’s on autonomous or autopilot mode. Now, if your vehicle doesn’t have a clear separation of these two systems, though, that could be a vulnerability that an attacker could exploit remotely to get messages into that CAN bus through the entertainment system’s internet connection. The third type of vulnerability we have is, if an exploit is set over the on-board Wi-Fi network. Now lot of cars over the past 5 or 10 years have added an on-board Wi-Fi service as a feature. If I’m driving close to your SUV or minivan and you have a Wi-Fi system embedded in your car, I could, in theory, connect to your Wi-Fi and then find a vulnerability to exploit that’ll allow me to send messages to your CAN bus. If I can achieve this, I can then inject messages into the CAN bus and take control of your vehicle.
Next, let’s talk about Modbus. Modbus is a communications protocol that’s used in operational technology networks that gives the control servers and the SCADA host the ability to query and change configurations of each PLC in a network. Now Modbus is basically a proprietary protocol, and it looks and functions differently than TCP/IP does. This is an important distinction. Because if you’re trying to do an instant response on a Modbus-based network, you have to use different things than all the things you’re used to using in a TCP/IP network that you’ve been using your whole life. For this reason, if you have a breach in your ICS or SCADA network, you really need to call in an expert for assistance because Modbus is a different protocol, and it requires a different way of dealing with it. If you try to use your standard incident response tools on an ICS or SCADA network, you can actually break a lot of stuff really easily. So make sure you don’t use tools that are designed for ethernet and TCP/IP on a SCADA network during an incident response. Because if it’s using Modbus, you’re going to break things. Instead, you need to get a specialist to help from the manufacturer of your ICS or SCADA devices to help you fix your OT network.
Now, originally, Modbus was designed as a serial protocol, known as the Modbus RTU. And it was run over fieldbus networks. Over time, though, some people have started tunneling that traffic over traditional ethernet and TCP/IP networks. Modbus is not the only protocol out there, though, as ethernet/IP is also commonly used in some ICS and SCADA networks. Ethernet/IP is a newer variant of older protocols like the common industrial protocol, known as CIP, the distributed network protocol, known as DNP3, and the Siemens S7 comms protocol. Next, we have the data distribution service, or DDS. The data distribution service is used to provide network interoperability for connected machines, and it facilitates the scalability, performance, and quality of service features that are required by modern industrial applications in ICS and SCADA networks. DDS brings a lot of modernization to our ICS and SCADA networks, including the ability to support both on-premise and cloud-based architectures and the complete automated orchestration of your connected components across the entire SCADA network. Finally, we have the SIS, or safety instrumented system. The safety instrumented system is composed of sensors, logic solvers, and final control elements like horns, flashing lights, and sirens for the purposes of returning an industrial process to a safe state after a predetermined condition was detected.
Essentially, our safety instrument system is designed to monitor our industrial processes and the ICS and SCADA networks that support them, as well as to detect any dangerous or potentially dangerous conditions that may occur. By detecting these conditions early, the goal is to reduce the severity of an emergency by taking quick action to prevent damage to personnel, equipment, and the environment. For example, I used to work at a nuclear power plant in Upstate New York early in my career. At that plant, we had a lot of safety instrument systems to monitor all of our operations and ensure that we would be notified of any unusual conditions quickly so that we could take remediation actions to prevent a major negative event like a core meltdown, which obviously will have a lot of people getting hurt or killed at the plant, as well as the surrounding towns. And it could destroy our equipment, and more importantly, our environment for decades or centuries to come. This is why safety instrument systems are so important to your industrial processes.
147. Data Storage Vulnerabilities (OBJ 3.5)
In this lesson, we’re going to talk about data storage systems and their vulnerabilities. Now, in any data center, there’s going to be a lot of different servers that require processing, storage, and distribution of different data for all of the different network clients. This means we have to have a place to store all this data. In general, there are three type of of systems that we use to store data. This is Direct Attach Storage, Network attach Storage, and Storage Area Networks. When we talk about Direct Attach Storage, this is any kind of storage that is attached to a system itself. Such as a hard drive inside of a server or workstation, instead of it being accessed over a network connection. Now, the other two types Network Attach Storage and Storage Area Networks, are those that are going to be accessed over the network. With Network Attach Storage, this is any group of file servers that are attached to the network, and they’re dedicated to provisioning data access. When you deal with Storage Area Networks, this is an entirely separate subnetwork, that is consisting of storage devices and servers, that are used to house a large amount of information. Now, the big difference between a Network Attach Storage and a Storage Area Network really is the way that data is read and written to that particular storage device. When you talk about a Network Attach Storage device, this means you’re going to be connecting to this device over the network, and it’s going to have its own file system to serve up those files. On the other hand, when you’re dealing with a Storage Area Network, this is actually a network based connection and you’re going to be reading to and writing data to that storage array based directly on block storage capabilities without the need of an underlying operating system. Now, as a penetration tester, it’s important for you to to understand what kind of vulnerabilities exist, inside these different data storage systems.
This can involve misconfigurations, underlying software vulnerabilities, different types of error messages and debug handling that can release sensitive information to an attacker, injection vulnerabilities, and lack of user input sanitization. Let’s take a look at each of these. First, we have misconfigurations. And this is the most common way that an attacker can exploit a data storage system. Anytime there’s a misconfiguration in the device, it usually is going to rely on having improper access rights or improper permissions, to the data being stored on that device. When those permissions are set too loosely, it can allow on attacker to gain access to the device and exfiltrate that data. Another cause of misconfigurations is the use of default or blank usernames and passwords which gives anonymous access to the data contained on those storage devices. Additionally, you might see data on the network that shouldn’t be exposed to that network. And this is called a network exposure. Where that data is being able to be accessed by anybody on that local area network, when it really should be tied down to a specific user, or a certain user group. Second, we have underlying software vulnerabilities. When you’re dealing with something like a Network Attach Storage array, it has its own operating system that’s being used to give you access to the data on that system.
If that operating system, which is normally an embedded form of Linux, has some vulnerabilities inside of it, that software can be exploited which can give you root access to the device, and access to all the information stored on that in the Network Attach Storage device. Third, we have improper error messages and debug handling. If the data storage system that you’re trying to attack gives you error messages, you can actually use these error messages to learn more information about that system and further continuing your attacks. For example, if you try to connect to something and it doesn’t work, it should give you a more generic message like, “Unable to connect.” But if the software developers who created that system actually create detailed messages, such as, “Could not connect to the management server “located at this directory,” that actually gives you additional information, so you can know where to target and where to attack. If the system provides that type of information and does really detailed error messages, that can be additional information you can use as a penetration tester to gain further access into that data storage system.
The fourth vulnerability you can try to exploit is an injection vulnerability. Now, there are lots of different ways to do injection vulnerabilities as we’ve talked about in the past. These include command line injection, DLL injection, and SQL injections. All of these are different types of injections that you can use to try to put data into a data storage system that shouldn’t necessarily be there. If you’re able to inject this type of data into that data storage system, that can then be read by other programs and this can cause other errors or exploits to be run. The final vulnerability you might be able to exploit as an attacker is a lack of user input sanitization. And this goes hand in hand with our injection vulnerabilities. The reason is if that system is programmed not to sanitize user input, or to use (indistinct) queries, it’s going to allow you to put data into those systems that it shouldn’t allow you to do.
This can lead other exploitations like cross site scripting, and SQL injections, as well as many others. The final thing we need to talk about is the management interface vulnerabilities that are associated with Intelligent Platform Management Interfaces, or IPMI. Now, IPMI is an Intelligent Platform Management Interface. And this is essentially a system that allows administrators to easily monitor and control all their servers, from a essentially located interface. If it’s configured correctly, this will restrict access only to authorized people such as the system administrators. But if this interface is not properly configured, it is an excellent place for you to attack. Because from here you can expose the network and all the data it contains. If you’re able to identify an Intelligent Platform Management Interface on the network and gain access to it, it really is an exceptional place to be able to attack anything you want on that enterprise from a common command console, that has far reaching capabilities.
148. Virtual Environments (OBJ 3.5)
Virtualization is important to the security of both our on-premise and cloud servers. Now, virtualization has continued to increase in recent years, helping reduce the need for additional power, space and cooling for our server rooms, and reducing the physical architecture involved in supporting our information technology operations. While I have personally heard management and executives say things like, we don’t need to worry about security. We’ve shifted all those services to the cloud. This is simply not true. The same security issues that we have with a traditional physical server are still going to occur and must be mitigated within the virtual or cloud networks. Now, what is virtualization? Well, virtualization is a host computer that’s installed with a hypervisor that can be used to install and manage multiple guest operating systems or virtual machines, which are known as VMs. Now, what does this look like? Well, essentially you have a piece of hardware that’s called the bare bones or bare metal, and then you install some sort of virtualization software on top of it, and that will be known as a hypervisor. Now, the hypervisor actually comes in two types. You can have a bare bones or bare metal hypervisor, where it runs natively on the hardware, or you can have an operating system with a hypervisor running on top of that operating system, and this is our second type. So, for example, on my laptop, I have a MacBook Pro, and on that MacBook Pro, I have the Mac operating system. And in that Mac operating system, I’ve installed a hypervisor known as VMware that I can actually run Windows on inside of a virtual machine on top of my Mac. Now, as part of that hypervisor virtualization, I can then install the guest operating system, in my case Windows, and then any applications that I want.
So, on my particular Mac system, even though I’m running Mac as my OS, as the host operating system, I have a virtual machine that has Windows 10 on it, and I have another one that’s running Ubuntu Linux. I have another one running Colly Linux and things like that. That way, I have access to all of these operating systems for whichever programs I need, or whatever demonstrations I’m trying to do in my courses. So, when we’re using virtualization, each server or host is going to run its own operating system inside of that virtual machine, but the virtual machines are run on top of the hypervisor. A hypervisor is used to manage the distribution of the physical resources of a server or host to those virtual machines, including the amount of processing, memory, and hard disc space that each one is going to get. Now, as I already said, hypervisors come in two different types or flavors. We call these type one and type two. A type one hypervisor is also known as bare metal, or native because it runs directly on the host hardware and it functions as the operating system itself. Examples of this would be things like Hyper V, Zen Server, ESXi and vSphere. All of these are type one hypervisors. Now type two hypervisors, run from within a normal operating system. Something like Windows, Mac OSX, or Linux. For example, if we use VMware workstation or Virtual Box inside of a Windows 10 desktop, that is considered a type two hypervisor.
With either a type one or type two hypervisor, we still need to ensure that each virtual machine runs its own copy of an operating system. Something like Red Hat Linux, or Windows Server 2019. These servers all require the same updates, security patches, and hot fixes, just like a traditional server would. So, we have to keep track of each of these virtual machines and make sure that we have its security posture well in tune. Now, virtualization is everywhere in our enterprise networks. And what began with virtualized servers has now moved into the desktops with virtual desktop infrastructure or VDI. These systems can host desktop operating systems within a virtualized environment that’s going to be hosted by a centralized server or server farm. This is a virtualization implementation that separates the personal computing environment from a user’s physical computer. The end user is then able to access the virtual desktop from a thin client or through a web browser, and then they can interact with that virtualized desktop as if they are sitting right in front of a standard desktop computer. So, for example, I have a Windows 10 machine that I can access in the cloud as part of a VDI network. So, if I want to use it, I launch a piece of software on my Mac and it reaches out to the cloud, and I connect to that Windows 10 machine and have access to all the resources I need being run on that cloud.
Now these VDI services have all the operating system, the applications, and everything else I need to operate this Windows 10 machine. Every time I try to run a command it processes it on that cloud server. It doesn’t process it on my local machine. Instead, my local machine is just a dummy box that’s used to connect to it. That’s the idea of VDI. This allows you to have it on a desktop, a laptop, a phone, a tablet, anything. It really doesn’t matter because the device is just there to connect to the server and run that virtual image, which is just going to be doing all the processing of the data for you on that remote server in the cloud.
And so, as I’ve been saying, this server is now performing all the application processing and the data storage. This means you can use a Chromebook, a MacBook, a Windows machine, and again, it really doesn’t matter because with VDI, we’re really focused on just connecting to the VDI environment, but all the processing is being done on the application and the server side for you. Because of this, many enterprise networks are going through an evolution into VDI with a lot of companies completely offloading their entire IT infrastructure by using third party services that use VDI. It’s really tempting for a CIO to do this because now they don’t have to run the operating systems anymore. They don’t have to worry about patching them because a third party provider can do all of it for ’em. That’s one of the huge benefits of VDI, and one of the main selling features, but it isn’t all good news. One of the bad things about VDI is that users have no local processing ability.
So, if the server is down, or the network goes down, or the connectivity is down, your users can’t do any work. So, if there’s an outage on that server, everybody is down. Whereas right now, I’m sitting on my laptop, and if my internet connection goes out I could still do my work, but in VDI, I couldn’t do that because if my network connection goes down I can’t reach the server, and so I would be out of luck. So, these are some of the things you have to think about as considerations when you talk about moving to a VDI based virtualization solution. Now, there are currently three models for input lending virtual desktop infrastructures within our network. The first is a centralized model, and this hosts all the desktop instances on a single server or server farm. The second is a hosted model. In this model, the desktops are instead maintained by a service provider and provided to the end user as a service. We call this DAAS, or Desktop As A Service. Services like Amazon Workspaces, VMware Horizon Air, and Citrix Zen Desktop, are just a few of the most popular providers of this service.
The third model is a remote virtual desktop model which involves copying the desktop image to a local machine prior to being used by an end user. This model eliminates the need for constant network connections and has much less requirements for bandwidth than the other two models. Now virtualization usage across the industry has really grown exponentially. Virtualization began with server virtualization, then went to virtual desktop infrastructure or VDI, and now it’s expanded into providing applications to users from a central location as well.
There are really two models used to provide virtualized application services. These are known as server based application virtualization or terminal services, and client based application virtualization, known as application streaming. Now terminal services is a server based virtualization solution that runs the application on servers in a centralized location, and the users access that application through remote client protocol, like Microsoft’s RDP or Citrix’s ICA. Examples of this are Microsoft Terminal Services and Citrix XenApp.
Application streaming, on the other hand, is a client based virtualization solution that allows an application to be packaged up and streamed directly to a user’s PC. This creates a sandbox application computing environment, that’s isolated from the user’s operating system. Now Microsoft’s App V is a great example of this technology. The benefits of using either terminal services or application streaming is that we can actually force additional security protections onto it. Things like encryption, access control to the server, and preventing data from being stored locally on an end user’s machine to help ensure the security of that data.
