 Good morning everyone. So as Larry just mentioned today, we're going to talk about an ICS specific talk and we will discuss the specific use of some modules function by Schneider in order to perform some bad actions on PLC. Just a quick introduction, this is nothing new. Everything that I'm going to mention today was discovered maybe 10 years ago, mostly by reverse ICS from digital bond at the time. However, I will try to show how it is still relevant even in newer PLCs and also how we can use that to perform a new kind of attack. So just a few words about me, my name is Arnaud Soullier, I'm French as you can probably hear. I mostly do pen tests, a bit of research and development. I'm a manager at Wavestone, that doesn't mean I manage anyone. I really, really love ICS, really fun to play with and I've given a lot of ICS workshop where I teach people how to perform entry-level pen testing on ICS at Black Hat Europe, Brucon, Defcon, besides Las Vegas. And I also like other things like active directory security and other stuff I'm not going to talk about today. So I'm not sure that everyone is familiar with ICS here so I'm just going to try to give a crash course in one minute or something like that. So ICS mean industrial control systems, those are the system in charge of, let's say, managing all the automation at plants and factories in all kind of sector. If we take a look at this diagram, you will see that an ICS is composed on the far right side of sensors and actuators. Sensors will give you an information, for example, a switch will tell you if it's switched on and off and one actuators will perform an action. For example, if you take the simplest example, it's a light bulb, you see that it emits light or not. Those physical devices that are managed by PLCs, that's the device we're going to talk about today that stands for programmable logic controllers and mostly it's an embedded computer with electrical inputs and outputs. That's the main difference between a standard computer and a PLC. Those PLCs are then managed by some classical IT stuff like Windows, servers and workstation running what we will call today a SCADA software. I'm not digging into the detail of SCADA versus DCS and stuff like that. Today we're going to call that SCADA. And somehow this is connected to the corporate network to get some information or send some batch orders. Okay, so there are a lot of ICS protocols. Today we're going to talk about Modbus. It's one of the most widely used, I think, discovered, invented in 1979 by a company that was at the time called Modicon and later bought by Schneider Electric. It was designed to work over serial lines, so RS485 mostly. There are two versions of the protocol, the binary and the ASCII. And if you take a look at a frame format, you will see that it's composed of the address of the PLC. Then what is called the PDU, the protocol data unit with one function code and the data and some kind of cyclic or linear redundancy check to make sure that we have data integrity. So what do I talk about the frame format just to show you that there is no security built into the protocol. There is no encryption, there is no authentication. So that was not really a problem when we were using that over serial lines. However, later they tried to use Modbus over TCP. So they just removed the integrity checks because that's handled by the TCP layer. And Modbus TCP frame format also has the PDU, so the function code and the data. And as a transaction identifier, that's a random number that is used to make sure that the request and the response match. A protocol identifier which is usually has the value one, not really useful. The length of the packet and the unit identifier. Most of the time the unit identifier is set to one because we already have the IP address to identify which PLC we talk to, so we do not need to use this field. Mostly Modbus is used to perform read and write actions. So here you have the most common function code. It's mostly used to read some information, a coil which is one byte or a register that is eight bytes. As you can see when Modbus was transferred to TCP, they did not add any kind of security, so still no security. So this is a protocol that's used for ICS, there is no authentication, no encryption. You can perform other kind of actions. For example, there are some basic diagnostic functions built in like the function read device information. That's a screenshot of this kind of request to this PLC which is a Schneider M340. As you can see, we can know the fact that it's a Schneider electric PLC and also get the detailed hardware information, so BMX P34. So that's interesting, but there are other kind of Modbus function codes that are used and not part of the standard. So we will focus on the Schneider PLC. So I do not have knowledge of all the PLCs that are produced by Schneider. However, I've encountered several kind of products. The first one and the oldest are the CanTum one, then the premium, then this one, the M340. And then we have newer models, the TM221 or 241 and the M580. So those PLCs, they are programmed by engineers using a specific Schneider software which is called Unity Pro. And what we're going to see is that Unity Pro is actually relying on some specific Modbus function code to discuss with the PLC and to program it. So how do we do that? It's quite simple. You install a demo PLC, you install Unity Pro, you launch Wireshark and you take a look at the packet dump. So as you can see, here's a packet dump when I log into a PLC and upload a new program. It runs on top of Modbus TCP. The function code is 90. It's already part of the Wireshark de-sector. So as mentioned, the use of Modbus function code 90 is not something new. It has been known for years. And when I first started working on it, I had a chat with, I think it's Alexi Lagout, a Wireshark developer in France, and it was kind enough to add this to the Wireshark Modbus TCP de-sector. So now if you take a look at Modbus traffic, you will be able to know when there is somebody performing admin actions on a Schneider PLC. Something else that's really important, I mentioned that in the introduction. All of this is already known. The fact that you can upload a program to a PLC is known since at least 2012. It was done by a reverse ICS. So what I did was during an assessment, I think it was maybe five years ago, I was facing a Schneider PLC. So I take a deep look at what Red did and what I try to do is try to build on that to add additional features or to make the metasprite modules more reliable. Okay, so now we see that using Modbus function code 90, we can do everything that can be done with Unity Pro, the programming software. So what kind of evil things can we do? First thing, not really offensive, is to gather some information about the PLC and the project and I'm going to try to demo that. So here on my setup, just to be clear, I have a Schneider PLC M340 and this is my laptop that will host both the attacking VM and the legitimate HMI workstation. Well, actually I did not plan on how I was going to type and have the mic at the same time. Thanks a lot. Okay, so the idea is that I'm using a new metasprite module that I just developed this week and I'm going to try to see what kind of information we can gather from the PLC. And hopefully it will work. Yes. So as you can see, I'm able to get the same information as using the Modbus function code 43. So the BMX is the hardware CPU of the PLC. That's the name of the project that's under the PLC. And from time to time, I'm also able to get the host name running the name of the workstation running the programming software, the version of the Unity software and the comments in this project. I think there are no comments. That's why we do not have anything here. Okay. So that was the first thing. Next, we can start and stop the PLC. So that does not mean we are going to shut it on or off, but actually the PLC will stay on. We can still perform admin action, but it will not execute the program. That's basically what StartSub did. I'm not going to demo that today. Why? It's quite simple. There is a module in metasploits. It works. It works greatly when you want to stop the PLC, but it does not work so well when you want to start it again. You actually have to unplug the electrical plug of the PLC and put it back again. So in order to, let's say, do not waste too much time today, I'm not going to demo that, but it works quite well, starting and stopping the PLC. Another thing that I want to show you is how to download the ladder logic. What I call ladder logic is actually the program that the PLC is executing. So that is also something that Red had worked on, but during my assessment a few years back I discovered that it was not working correctly. Why? It's quite simple. I think he used a demo program, so really small in size, so there was a misconfiguration with the size of a counter in the specific Schneider protocol. Okay, so here you can see that I'm going to attempt to download the program and to store it at this location. Okay, so there are a few modules requests that are sent to the PLC. The Ethernet card is flashing and in a few seconds we should have the program. It's a very simple program, just managing a traffic light, so it's quite fast. Okay, so here I have my file. So now what I'm going to do, I want to make sure that the file that I downloaded is the real one. So I'm going to switch to the other VM, which is a Windows one. I'm going to connect to the PLC. Oh yeah, it's not working. Yes, it works. I'm going to download the project from the PLC to my PC. Okay, so now I have on my PC the same program as the one running on the PLC using the legitimate software. I'm going to save that as an archive on my desktop. Okay, if I take a look at the desktop, I'm going to try to find this file. Okay, it's here. I just have to rename it because it's actually a zip file. And if you take a look inside this zip file, you see that there's a hidden folder called binapply. And in this folder we have the station.apx file, which is actually the one that has the PLC ladder logic. So I'm copying this file to a share to the other VM. Okay, I'm replacing the file. And if I go back here on my Kali Linux machine, okay, so I'm actually doing a binary diff between the file I just downloaded and the one that I just copied from the legitimate software. And as you can see, the files are identical. So the module works. It's possible to download the ladder logic. It should be possible to upload it as well. However, I have the same kind of issue with the counter and the size of the counter. So at the moment, the module in Metasploit or the one that I developed does not work correctly. Okay, so those were the things that already existed. But since this is DevCon, I wanted to have something new. So one feature that was really interesting to me was what we call forcing the outputs. I don't know if you have already worked on the PLC. Forcing the outputs is used during the development phase that allows you to bypass the control, the ladder logic of the PLC and directly set the outputs to on or off or any kind of arbitrary value. And that helps you debugging, especially when working with other entities. So that's interesting why the way PLCs are developed most of the time on the SCADA HMI, you do not read the values of the outputs. You read the values of some intermediary variables. So for example, if I go back on my Windows workstation, so here I'm going to launch the SCADA software. Okay, so basically this controls the PLC. As you can see, I can switch the lights on and off. The way it works is that I'm not directly reading the outputs because that's not a feature that this specific software has. What I'm doing is actually, if I take a look at the code, let me zoom on that. So as you can see here, I have three variables, red, green and orange, that will set the outputs to one or zero. That's the way it works. So I have modbus values that are managing the values of the outputs. From what I've been able to discuss with people, engineers working in automation, most of the case, that's how it works in ICS. You never use directly the outputs. You use some kind of intermediary variables because in real life, you will use some complex function blocks and it's not as simple as just one switch. Okay, so that's interesting because what happens if I want to directly modify the outputs? What will happen on the HMI screen? Probably nothing. So that's what I'm going to demo here. Let me see. Okay, I'll go back to Kelly. So here I'm just going to use the other module. I will launch a specific action that will set every output value to zero than one. And that for all the eight outputs that I have on this specific PLC. So the idea is that I should be able to modify the real process without the operator noticing anything on the screen. So that's what I'm going to try to do. Okay, so the module is running. So at some point, we should see the light changing. It should not be part of the HMI screen. Let's wait a few seconds. Yes. So as you can see, I'm switching the first output to one, but that's not displayed on the screen. Then I'm going to do the orange one, set to one, then zero. But it's going to stay orange on the screen. There's a five second delay that may be a bit much. And the last one will be the green one. No, the orange again. Okay. So as you can see, I was able to badly influence the physical process without having any kind of information displayed back to the operator. Okay, so that's interesting. Other topics I'd like to work on in the future is the ability to hot patch the PLC. Because actually when you program the PLC, you have to stop it, upload the program and start it again. So in the physical process, anyone will notice that. However, using Unity 4, you can also hot patch. That means you can perform some small modification of the ladder logic without having to stop the PLC. So that's really interesting. And I'd like to have a metasploit module that does the same. For the record, I also have another module in the works that does not force the output's value, but the register's value. So you can actually modify any action inside the ladder logic, as you wish. Okay, so that was true for the premium, the quantum and the M340 PLCs. What about the newer ones? So in 2015, I bought the new release TM-221. So those are entry-level PLCs. And what I've discovered is that even if they are not programmed by Unity Pro, but another software called SoMachineBasic, they actually still use the same function code. So even the PLCs released two years ago, even if we know that there was no authentication on admin actions since almost ten years, the new PLCs still have the same problem. However, the exploits, they do not work out of the box. You actually have to perform some kind of modification, change some offsets. So it's vulnerable, but you cannot prove it at the moment. One of my colleague, Alexandrine, she already had parted some modification to the metasploit module. So you can now start and stop those devices without any kind of authentication directly from metasploit. So that was three years ago. I recently learned that the new high-end M580 PLC adds IPsec authentication, so between the engineering station and the PLC. So that's a good thing. They actually use IPsec not for encryption, but only the authentication header part. So that allows you to make sure that if you want to program the PLC, you have to know the pre-shared key. So that's a good thing. However, that's quite new. It's the high-end PLC, so a CPU is at least, I think, $4,000. So at the moment, I do not have the money to have that in my lab, so I cannot vouch for it. But that's a good idea, and that's the way things should work. So we can hope that in the future it will work. However, this is something quite new, and you will probably not see that in Plants and Factory for at least five to ten years. Okay, so what do we do now? Is it possible to, let's say, configure the PLC in a way that allows you to defeat those kind of attacks? To the extent of my knowledge, no. Actually, there are very few things you can do on a PLC. I think that on some Schneider PLCs you can, there is some kind of integrated firewall, but it works not like a firewall because you can actually send a mod... It's at the application layer, let's say, not at the network layer, but you could use that to prevent unauthorized action. Using newer PLC will work only if you buy the latest one, so it might also be difficult to implement in, I would say, in existing or legacy environment. And of course, what you can do is perform network security monitoring. As mentioned, those attacks are not new. The exploits are new, but the vulnerability is known for a long time, so there are signatures for this Modbus function code. So if you're using any kind of network security monitoring in your ICS, you will be able to detect any kind of attack. I would say that you should log any time an engineering station logs to a PLC to perform admin action. And of course, if you have an unknown workstation doing Modbus 90 traffic to a PLC, that should raise a really, really red alert. Okay, so to sum things up, most Schneider PLCs that you will find in assessment are vulnerable for 10 years to this unauthorized access vulnerability. Attackers can leverage that to do whatever the hell they want with the PLC, including forcing directly the outputs which might allow them to perform some kind of stealthy attacks on your process. So what can you do? I would say at the moment you have to deal with it. Okay, so before I take any question, I'd like to say that everything is at this GitHub address at the moment. I really hope to be able to clean up the code and do a pull request to metasploit, but they're quite picky about code quality and at the moment it's pretty shitty. So in a few months, I hope to be able to do a pull request to put that directly into metasploit. But you can find that today on GitHub as well as the slides and a few videos of me testing PLCs. So do you have any questions? Also, I'll be happy to play with other kind of PLCs. If you have, for example, Schneider PLCs that I do not have, it would be easier for me to try to understand the protocol. So if you have a M580 or a TM241, I'll be interested in testing that. Or you can also download the modules, test on your own and give me some feedback on GitHub. I would love to do that. Okay, so if there are no questions, thanks everyone. And I'll be around the ICS village a lot I think during DEF CON. And if you're interested into ICS, of course, you just go across the hall and you will find a lot of PLCs to play with.