Hacking PLCs and Causing Havoc on Critical Infrastructures
Alves, Thiago
Programmable Logic Controllers (PLCs) are devices used on a variety of industrial plants, from small factories to critical infrastructures like nuclear power plants, dams and wastewater systems. Although PLCs were made robust to sustain tough environments, little care was taken to raise defenses against potential cyber threats. As a consequence, threats started pouring in and causing havoc. During this presentation I will talk about the architecture of a PLC and how it can be p0wned. There will be some live demonstration attacks against 3 different brands of PLCs (if the demo demons allow it, if not I will just show a video). Additionally, I will demonstrate two vulnerabilities I recently discovered, affecting the Rockwell MicroLogix 1400 series and the Schneider Modicon M221 controllers.
 Alright, it's about that time to get the show on the road. So everyone please give a very warm welcome to Chiyago who will be talking about hacking PLCs. Sorry I have a little experiment here. It took a little longer to set up than I was expecting. But I am very very happy to be here at DEF CON today and I was honestly expecting like 50 maybe 100 people. So thank you guys for taking the time to be here on Saturday morning and listen to me. I am Chiyago Alves and a little bit about me. I am a PhD student at UAH and I also work at the center for Cybersecurity Research and Education. It's called CCRE at the university. And yes, this is what I do. I love to hack stuff and I try to break as many things as I can. And I'm also the creator of the Open PLC project. If you guys haven't heard of it, you'll hear about it a little bit today. So heads up if somebody has heard about Open PLC before. Wow, thank you. That's great. That's great. Thank you. Also today, it's a very important day for me because this trip to Vegas marks our ninth year anniversary. Me and my wife were together for 90 years and yeah, I used to have more hair back then but she's still pretty the same way. So I'm a lucky guy. And she always complained about being like slowing me down because now we have kids and I have other things to focus on. But I keep telling her that if you want to go fast, you go alone. Life is not about speed. But if you want to go further, if you want to go far, you go together. That's why I'm here. That's because of you. Right? And I'm very happy. I invited her to be here at my talk. Thank you. And she has a very important job actually because I have really bad jokes and she laughs of all of them. So if you hear her laughing, just please laugh as well. So we have a nice presentation. Okay? Okay. So a little outline about today. I'm going to start with a background info. You know a little bit about PLCs. If you guys know about PLCs, I'll try to go fast. If you don't know about PLCs, please pay attention because I will go fast. Okay. Then we'll go and talk about a little attack vectors, some stuff we can do to break those things. And finally we'll demo. If the demo demons haven't gotten me because I didn't have enough time to set up. So hopefully things will go out fine. So what is a PLC after all? It is, that's what it looks like. Right? It's a brick. And it stands for Programmable Logic Controller. And basically it's a digital computer. It's used on automation since 1970. So it's a long time ago. And basically it is an embedded system with a CPU, some RAM, some ROM, some flash nowadays. And you put your program in there, you run your program. And your program decides what to do with the input data it senses from the input modules the PLC has. So PLC has a bunch of inputs, a bunch of outputs. I have three PLCs set it up here trying to heat water. And they're doing a poor job doing that. But then you program those devices to any logic you want. And it has output modules to control real life stuff. Right? So for example in this setup it's controlling the heater based on the temperature sensor that is attached to the input module. And you will see PLCs in many different places. So here I have like a dam, a substation, a gas distribution system in a petrochemical facility. And PLCs are there. And you imagine what happens if you hack into those PLCs and make a crash, right? Or change a setting. So for all those situations a disaster will follow if you break into a PLC. Because they are controlling large, huge stuff that can cause even physical damage and life loss, right? So what is the problem with the current PLCs we have? First of all, they are freaking expensive. You know, if you're building an embedded system it shouldn't cost that much. Nowadays there are some companies selling what they call cheapo PLCs. You can buy one for like 100 or 200 dollars. But then they get you on software. There are companies selling software, programming software for PLCs for up to $5,000 per station. And that is ridiculous, right? That is ridiculous. And also they rely on very legacy technology. PLCs were built like 40 years ago. And that's also a major problem because this legacy technology was created at a time that internet didn't exist. So they use unsecured protocols to communicate. Most companies rather patch their devices instead of redesign. We are in a situation where we need redesign and they are closed source. So this is a problem if you are a researcher and trying to figure out how they work. So I came up with a solution. If you guys know about it, open PLC. That's my thing, right? Open PLC is the world's first and only one PLC available with the full source code. There are other approaches that people try to develop their own PLCs, but it is not closed to what a PLC should look like. PLC, there are many standards that define what a PLC should do and how it should behave. And I try to follow those standards close so that it will look like a real PLC and behave as much as possible to a real PLC. And I make the source code available. Anyone can go take a look at the code and use it. It is free, right? And basically open PLC has three main components. The runtime, that is the big thing that I am creating, is the thing that goes into the embedded system, embedded device. Initially I started creating my own hardware, but then I gave up and started using Raspberry Pi, Arduinos and stuff that everybody have. So you can load the runtime on your embedded system and have it read your PLC programs. You create your PLC programs on the editor that is supposed to run on your computer, right? On your Windows, Linux, machine. Some folks have ported it to Mac OS as well. And the third portion of it is KWR, which is a GUI builder that allows you to create nice animated graphical screens for your PLC programs, right? So for the open PLC runtime, it runs on many different platforms. These are the platforms that are currently supported, officially supported. Like I said, Raspberry Pi, Arduinos, but also there are some industrial devices that people created that also runs open PLC, like UniPi and Pi Extend. This is really cool. You can go and buy those devices and install open PLC today if you want. There are other devices that are not here. They are not officially supported. They were created by the community. So I have a forum with lots of people in there and they, you know, make all sorts of questions. And they also contribute to the project and they created unofficial patches that make open PLC run on like Orange Pi and other platforms that basically run Linux. This is the editor, what it looks like. It supports five programming languages. These are all the five languages defined on the standard. And this is KWBR, right? This is a real nice graphical screen created on KWBR. So it can create many things. This is the water temperature control you're going to see today. So let's go to talk about PLC protocols for a bit. I don't know if you touched on SCADA protocols before, but what it looks like. There are problems with those protocols. Basically, most protocols today are derived from legacy serial networks. So if you're old enough, you might remember those RS485 networks where you hook up a bunch of devices on a serial cable and all the devices receive the same message and they decide if they want to accept it or not. This is great for hacking, right? You just listen to the bus and you get everything. There is no authentication, of course. There is no integrity. And when I mean integrity, I'm not talking about error correction. I'm talking about if somebody tempers the message, is that going to be figured out at the other end or not? So they don't have any integrity mechanisms. And there is no confidentiality. So the message goes on the field with no confidentiality, which means it goes in plain text. So the most popular SCADA protocol is Modbus. It's about 90% of the PLCs support that. Actually, I haven't found any PLC that does not support Modbus. They usually support their own protocol plus something else plus Modbus. Everybody talks Modbus. And in essence, Modbus is very simple. There's nothing very complicated with that. It is, of course, based on serial networks. And the commands, basically how it works is that the commands for the protocol are encoded into function codes. So you have different function codes for different things you want to do. And it's open. That's probably why everybody supports Modbus because it doesn't require any licensing. You can go and pay Modbus Foundation to have your device certified so that they make sure that your device is actually following the full standard. But you don't have to do that to support the protocol. There's no licensing, right? Licensing fee. And this is the Modbus frame. That's what it looks like. Basically, the first byte is a slave ID. And the slave ID is a unique address because it was based on serial networks. So you have to have a way to address a device. The function code is what I was talking about. It tells the slave device what to do. It's like the command it should obey, right? And the function code varies from reading or writing to memory areas. Data. Well, data is data, right? It depends on the function code you're using. And finally, CRC, it's just error correction verification. Again, this is not checking integrity of the message itself. It's just checking if there are any physical errors that happened on the transmission, right? If somebody can tamper with this frame, change the data, recalculate CRC and send it through, it will go, right? It will be accepted by the PLC. So those are the most used function codes. There is function codes to read digital outputs, to read digital inputs, and also to read and write registers. Basically, all it is is working with memory. So Modbus gives you free access to the PLC memory. You can read whatever you want. You can write whatever you want with no authentication. Who loves that, right? They updated Modbus to make it compatible with TCP IP networks. What it means is that they added a frame on top of the Modbus frame. So basically, it has a transaction ID to keep track of all the transactions you're making. So if the host makes a transaction, it makes a random number on that transaction ID. So when it receives a response, it might receive a bunch of response from the same slave device. And it will match the transaction ID to make sure that that response is related to the query it was making. Protocol ID. It seems that originally Modbus on TCP was meant to work with other protocols as well. So they created this field so that different values on that field will mean different protocols. I've never seen anybody using anything different than 00. And 00 stands for Modbus. So I think they field on this. Length is length, right? How many bytes there are after it. And after that, it's just plain serial Modbus frame as it was before. They kept the slave ID byte on that frame because some people would just convert between TCP IP networks and serial networks. So you have all devices talking serial and new devices talking TCP. So keeping that byte over there means that serial devices will also be able to receive that message, right? Even though if they are addressed on TCP. For TCP only PLCs, usually that byte means nothing. They will accept anything. Tax scenarios. What can we do with this? So you can create a few different attacks on that. Because the message is so simple, you can just interrupt the communication and cause a denial of service. There are many ways to do that. You can intercept the message and read the contents because there is no encryption. No confidentiality at all. You can also modify the message. You get the message, you get a bump in the wire or some sort of either cap or poisoning hack. And you get the message since it's plain text, you modify the contents, send it back. Yeah, that is pretty disastrous. And my favorite, injection. You can only just send a freaking frame. The PLC will accept you, right? It accepts everybody. So let's demo it. Hopefully it will work. So I have here skatobr. And let me start the last PLC. I didn't have the time to do it. Hopefully I will now. Let me get back to skatobr. So this is skatobr for you to get familiar with it. It's an old tool, but it works very well. And I incorporated it into the Open PLC project so that we can update it and renovate it over time. So here I have all my data sources. These are all my PLCs. So here on the table, I have three different PLCs. The first one here is Open PLC running on a UniPy platform. This is an industrial platform. The second one is an Allen Bradley MicroLogix 1400 series. And the third one is a Schneider modicon M221. So let me go ahead and try to turn them all on. Hopefully they are good. So let me start this PLC as well. In the meantime, while this thing is starting, let me show you the graphical screen and see how it looks like. So this screen shows my system, my setup here. So what I have, as I said before, I have a cup filled with water and a water heater element inside it and a temperature sensor. The temperature sensor is connected to the PLC, so I have three identical setups. And since PLC is all ladder logic, I just created the same ladder logic for all the three PLCs. So they are running identical logic programs. Of course, each architecture will just interpret that logic differently internally, right? Some will compile that to binary code, that's in case for Open PLC. Some will just convert that to virtual machine that will just run interpreted instructions. So it varies by vendor, but they all, in essence, doing the same logic. I just copy paste the same ladder diagram to make sure they are all running the same thing. And on that configuration, I have a flexibility here that I can set the PLC for manual mode, turn on the heater if I want manually so you can see the heater going up here. Just a little break to turn on the PLC, sorry. And I can turn the heater off. I can put in auto mode. So the auto mode will try to keep the temperature around 40 degrees Celsius, and you know, temperature is a slow thing, so you might go up slowly and go down slowly. But in essence, all the PLCs are trying to keep that around 40, except this third little one because it's not on yet. Sorry about that. Let me just log in here, and in one second I will turn it on. So my job here is try to attack these PLCs. Once I am in the network, I will show you how easy it is to create a Modbus frame and attack it. Right? Last click. Not yet. Okay, should be good to go. Let me start it. Yes, I want. By the way, this is so machine basic. This is the software used to program the Schneider Modicon M221. We will have a lot of fun with that software today. Okay, so let me start my terminal here. So I have an injection attack ready. What this injection attack does, it tries to send Modbus packets that will switch the PLCs in manual mode and keep the heater on. Right? And this message will be sent over and over and over again, so that the operator will lose control of the PLC and will not be able to turn it off. Right? So I will start the attack now. This little attack, I hate sound. This little attack has two parameters. I created this software. By the way, everything is available on Mykit Hub, so if you want to get those tools, go ahead. You have it. So it has two parameters. The first one is the host. So the host is 100, 100, 100, 100, because I am really bad with numbers. I had to choose a good one. And the other parameter is frequency. I won't use it. The default frequency is 1,000 messages per second. So let's try that on OpenPLC. Go. All right, cool. Heater is on. Let's turn it off. Well, it doesn't work. So let's put it out of mode. It doesn't work either. I'm screwed. So that's probably what the operator will be thinking. You see the temperature going up, and you can do anything about it. And all it takes is sending freaking Modbus frames. That's all it takes. What I'm doing here is writing to a portion of the memory of the PLC that I know it's storing the setting for manual or auto mode and the other area that is storing the setting for the heater if it's on or off. That's all it takes. And I can guarantee you that this kind of attack works with 100% of the PLC that I know off. Right? So, okay, let's stop this because I have boiling water already. Let me put back on auto mode. We'll shut off the heater. Now, let's try the same thing with our friend, Alan Bradley. It is at the same IP except 101. I know. I'm bad with numbers. So, let's try that again. Boom. Oh, gosh, no. It's on. It doesn't work. Right? Auto mode also does not work. Temperature will go up. And, yeah, it works the same way. You see different brand of PLC, freaking same Modbus protocol. That's the culprit. Okay? Let me stop this. Auto mode again. Last attack. Let's try that on the Schneider modicon. Please, misbehave. Okay, it's on. Even though the temperature is also over the set point, it does not work either. Right? So, that's how simple it is. You can today start creating your own PLC attacks. Okay, let me stop this. Now, this was pretty fun. And I had a lot of fun creating this, but I have one more thing. For those of you who are a fan of Steve Jobs, this is where the best part happens, right? So, let's talk about micrologics. Micrologics is a PLC from Alan Bradley. And Rocko Automation, I don't know the history, who bought who, but they keep both names in, so I just say both names. But what are the fun facts about micrologics 1400 series? You should be buying one today to hack. It's a pretty fun device. Right? So, first of all, it runs VXWorks. VXWorks is one of the most popular real-time operating systems on the industry. It's on everything, right? Including PLCs. And there are a bunch of vulnerabilities reported for that device. Guess what? I bet most of those works with Alan Bradley as well, right? It is one of the most popular Alan Bradley PLC. You see that everywhere. And it supports Modbus DCP. That's why the injection attack worked. This is my favorite feature. It can be killed remotely by sending a bad Modbus packet. This is great. So, let me talk about this, what I call micrologics deadly packets. Basically, all it takes, it's to trick the memory allocation algorithm of the micrologics PLC. So, what I do is I start a new transaction ID. Protocol, of course, is Modbus00. And on the length field, I say I will need 20, 256 bytes, right? But I only have six. All right? So, it might try to allocate that much memory, but it's only receiving less than that. And right immediately after, I start a new transaction ID where the length is the length of the previous packet. And it's incomplete. It stops at the unit ID. So, it makes the PLC confused with this memory management system. And I cause a buffer overflow, writing that message on a different area of the device, crashing the device and making it unrecoverable. So, let's try to do that. Okay. All right. So, just to check here, I should have everybody running. Wow. I laughed that PLC on for too long. All right. So, we're targeting Eileen Bradley now. It should be working fine. So, I'll just put in manual mode to prove like the heater is on, heater is off. Everything should work beautifully. Auto mode should keep the heater off. Let me just keep that on heater on so that will be more fun. So, let me go. It's hard to type when your hands are shaking. It should be Eileen Bradley exploit. This is also available on my GitHub. So, the only argument it takes is the IP address of the PLC. So, all it does is send those two deadly packets and let's see what happens when I do it. Dead. So, you'll see right now that the PLC is not communicating anymore. You see the exclamation point all around? Ha, dead. How cool is that, right? You can even try to press the buttons over there. It's completely dead. And you know the fun fact of it is if you power cycle, it's still dead. I'll prove it. I just power cycled it. And it will boot again. It managed to boot again, but default LED keeps on for some reason. So, yeah, it is booting up and you still see the exclamation points here. Till the end of the presentation. So, the problem is that application got corrupted so the PLC cannot launch it again. The fault mode is always on. The only way to make it work again is to reprogram it with the ladder logic. This is creepy, right? So, if you lost the ladder logic, you screwed. Please don't send it on the wild. There are too many micrologic PLCs out there. All right, let's behave. Okay, let me see if I have something else. This is a problem that affects all MicroLogic's 1400 series. I don't know about others because I'm not rich to buy all the PLCs, but I bet it also affects some other related series like 1100 and so. I talked to Alan Bradley through ICS-SERT. We published this vulnerability and they are really nice. They responded back and tried to work with me to create a patch. So, they released recently about a few months ago a firmware update. This firmware update fixes this vulnerability, although it's a pain to update it. I spent like half an hour trying to do that and I'm supposed to be a security expert. Imagine people out in the field what they will do to try to update this thing. They won't stop their factory to update their PLC firmers. Hopefully, the new PLCs that will be sold now will have this new update already built in. There are other mitigations where please disable Modbus TCP. This is not a fix. Dude, if you're disabled in the protocol, you're not fixing it. You're just disabling it. This mentality is common for all the PLC vendors that I usually talk to. Minimize network exposure, but PLC is behind a firewall. Basically, what they're telling you is the security is on you. We don't provide security. You're freaking alone. So, try to do your best. These are good practices, but I honestly believe that a PLC, the device itself, should provide any sort of security. And one last thing. All right. Schneider. There is a special reason why I brought the Schneider PLC with me. The Schneider has a protocol that is common to all the Modicon family. I think other families also use this. It's called Unity Protocol. At least me and some other researchers are working with this. Call it Unity or UMAS. You might hear both names. And this protocol is obscure. It is undocumented. It runs on top of Modbus TCP, so you have a normal Modbus transaction. But one, you have a function code 0x58. This is exo decimal for 58. This triggers the sub protocol that runs on the data field of the Modbus frame. And for the Modbus documentation, 5a is a reserved function code for specific vendor-specific functions. And this is a nice part. This protocol is used to configure and monitor the PLC. Down to the operating system level, you can do a total memory dump using this protocol. You can get the freaking operating system image using that. So this is crazy, right? It's proprietary and undocumented, so they try to make secure by obscurity, but that won't prevent us from figuring that out how it works. So basically, Unity have a bunch of function codes, so it's a function code inside a function code. You have the Modbus frame, and then you have the Unity frame. And these are the function codes you can play with. And I have to thank Luis Litas. He is a researcher on the same field. We started talking and communicating like one year ago, because I figured out he was working on the Unity devices as well, and we started contributing to each other. And he has a very nice blog, LitasEnlarred.xyz. You go, if you want, you can go and check it out. He has a step-by-step how he managed to get those function codes and reverse engineer the DLLs for the So Machine Basic and get that information. So this is pretty cool. And basically, you can take a look at some messages here. They're pretty cool, like read memory block. This is my favorite. Okay, so, but today, given the time constraint, we'll only play with a few of those. So basically, we'll start a communication, init communication. We'll read a project info to read some data about the project. This is also cool. Take PLC reservation. It means that the PLC needs to be connected to someone. Someone needs to reserve the PLC. If you take the PLC reservation, you're taking the other party down. This is DOS, built in the protocol, dudes. This is what? Right? So you just keep sending this take PLC reservation, and I think nobody else can connect. So release PLC reservation, and you're releasing it because you just don't want to communicate anymore. And start PLC and stop PLC will, basic main functions to start and stop the PLC. All right. So, let's play with it. I'll just keep this slide open so we can play a little bit with how it works. Is that up? Okay. So, I created also a little software, Modicon tester. I don't remember the name of the executable. Okay. So, this software was created in C sharp in a hurry. Please don't look at the code. It's messy. But the good thing is it works. And all I did was to create this thing to help me reverse engineer the protocol. So it basically encapsulates my messages on the Modbus frame with the function code 5a. So I can send anything and it will be accepted as unity messages. So, all you do, you connect to the PLC. It's already set up with the M221 IP address. I connect. And then it gives me the exodesimal output and the ASCII related to that. So let's start by starting our communication. So every function code has two bytes, 0001, and I'll end it with 00. So it just gave me back a hi. I'm here. That's fine. Hello. So let's go ahead and release PLC reservation. If somebody was talking to it, sorry. And then I'll take the reservation, 10, 00. And now the take reservation is an interesting thing. I don't know if you can see it. Sorry. I should have made it bigger. But I'll promise I'll read it right. The message is sending me back with the take PLC reservation. It ends with a magic byte. In this case, it's 8e. It's even smaller for me. So 8e, I mean, it's this magic byte that I need to send before any message that I want to send now on. Now that I have a session, I have a reservation, I have reserved the PLC for me, I'll have to use this magic byte. That means that before, people were trying to do replay attacks. So the replay attacks would be successful just because they didn't have any session management. So you could just get messages that the main station was sending and just replay that and it would work. Now you need the session number, but that won't prevent us from sending stuff. Right? So now let's play with this. I have 8e as my session number. You can see here, oh, urgent. Alan Bradley is not talking, still. Sorry. Sorry, dude. You can see that the modicon is still working fine. Temperature is 40 degrees Celsius. I can turn the heater on manually and off. Right? It works. So what I'll do here, I will send a stop PLC command. So I need to start with my 8e and then the stop message is 41. It ends with ff00 and let's see. Stopped. Now the PLC can still communicate, but the heater is off. I cannot turn it on. I cannot turn it off. I cannot put an auto or manual mode. It's off. How cool is that? So just by sending a few messages, I can have full control of the PLC. But here comes my favorite feature of this protocol. This is really interesting. So I'm going to use the So Machine Basic here for a second. Let me just create something new. So I'm just using their application to talk to this PLC over here. Right? And when I click here, it already identified my PLC, I try to log in and it's trying to log in. But this application is password protected. How come? So I cannot access my PLC without the password. If I try to type anything, it won't give me access. Right? All right. What can we do about it? Okay, let me get back to my Unity tester here. So remember that message, read project info? For some reason, that thing doesn't even require a session. So I'll go ahead and send this. 00, no session. 03 is the function code for that and 00. 00 will just get the header. So let's see what comes out of it. My header for the project that is stored on the PLC. And this is the name of the project. What is this? Yes, the freaking password. Right? So if I were Steve Jobs and I was working at Schneider, I would say this is not a buck, this is a feature. What if you forgot the password? The device needs to tell you that. Right? So let's try it. Defcon is my password. So when I type Defcon, boom, I mean, super hard. Right? Now I have full control of the PLC again using their own software just because I stole the password. And it works. I've tried with different, slightly different types of Modicon, M-something serious. And the same thing works. So, yeah, you can play with that. I can start the controller because I stopped it before. And I can see the programming on it. Yeah, I have full access. So this is pretty hilarious. Now, that's to show you how secure your PLC is. And imagine that those things are controlling your nuclear power plants and your water filtration systems. I'll just go live in a jungle. So, Schneider also, they were really nice. I submitted this through ICS cert and they talk with me and we try to come up with some mitigations. And they recommended the following things. Disable unity protocol. This is the best mitigation ever. So again, you see a different vendor with the same mentality. Just turn that freaking thing off. It doesn't work. Right? They also recommended, because of that password vulnerability and all of that, they recommended to store your project files in secure, access restricted locations, and encrypt your project files with reputable third party file encryption tools. Again, they're giving you the responsibility to fix stuff, to secure your settings. And this is pretty, it gets me worried. Right? And a little bit about what I plan to do in the future. By the way, I haven't showed you this. This is what Open PLC looks like. This is a web interface that is running on the device. So once you install the runtime, you have that interface up and you can see your programs. You can see your hardware. You can even mess up with the code live. Right? So it's pretty cool. And this thing is also vulnerable and insecure. I created it to be like that because I'm trying to mimic what other vendors are doing. So we can kind of research about it. But my PhD thesis is about creating a secure version of Open PLC that will try to prevent those types of attacks from happening. Okay? So it was really fun to be here at DefCon today. It was really an honor to me to be here. And thank you very much for coming and staying with me this Saturday morning. If anybody have any questions?
 Alright, it's about that time to get the show on the road.  So everyone please give a very warm welcome to Chiyago who will be talking about hacking PLCs.  Sorry I have a little experiment here. It took a little longer to set up than I was expecting.  But I am very very happy to be here at DEF CON today and I was honestly expecting like 50 maybe 100 people.  So thank you guys for taking the time to be here on Saturday morning and listen to me.  I am Chiyago Alves and a little bit about me. I am a PhD student at UAH and I also work at the center  for Cybersecurity Research and Education. It's called CCRE at the university.  And yes, this is what I do. I love to hack stuff and I try to break as many things as I can.  And I'm also the creator of the Open PLC project. If you guys haven't heard of it, you'll hear about it a little bit today.  So heads up if somebody has heard about Open PLC before. Wow, thank you. That's great. That's great. Thank you.  Also today, it's a very important day for me because this trip to Vegas marks our ninth year anniversary.  Me and my wife were together for 90 years and yeah, I used to have more hair back then but she's still pretty the same way.  So I'm a lucky guy. And she always complained about being like slowing me down because now we have kids  and I have other things to focus on. But I keep telling her that if you want to go fast, you go alone.  Life is not about speed. But if you want to go further, if you want to go far, you go together.  That's why I'm here. That's because of you. Right? And I'm very happy. I invited her to be here at my talk.  Thank you. And she has a very important job actually because I have really bad jokes and she laughs of all of them.  So if you hear her laughing, just please laugh as well. So we have a nice presentation. Okay?  Okay. So a little outline about today. I'm going to start with a background info. You know a little bit about PLCs.  If you guys know about PLCs, I'll try to go fast. If you don't know about PLCs, please pay attention because I will go fast.  Okay. Then we'll go and talk about a little attack vectors, some stuff we can do to break those things.  And finally we'll demo. If the demo demons haven't gotten me because I didn't have enough time to set up.  So hopefully things will go out fine. So what is a PLC after all? It is, that's what it looks like.  Right? It's a brick. And it stands for Programmable Logic Controller. And basically it's a digital computer.  It's used on automation since 1970. So it's a long time ago. And basically it is an embedded system with a CPU, some RAM, some ROM,  some flash nowadays. And you put your program in there, you run your program.  And your program decides what to do with the input data it senses from the input modules the PLC has.  So PLC has a bunch of inputs, a bunch of outputs. I have three PLCs set it up here trying to heat water.  And they're doing a poor job doing that. But then you program those devices to any logic you want.  And it has output modules to control real life stuff. Right? So for example in this setup it's controlling the heater based on the temperature  sensor that is attached to the input module. And you will see PLCs in many different places.  So here I have like a dam, a substation, a gas distribution system in a petrochemical facility.  And PLCs are there. And you imagine what happens if you hack into those PLCs and make a crash, right? Or change a setting.  So for all those situations a disaster will follow if you break into a PLC. Because they are controlling large, huge stuff that can cause even  physical damage and life loss, right? So what is the problem with the current PLCs we have?  First of all, they are freaking expensive. You know, if you're building an embedded system it shouldn't cost that much.  Nowadays there are some companies selling what they call cheapo PLCs. You can buy one for like 100 or 200 dollars.  But then they get you on software. There are companies selling software, programming software for PLCs for up to $5,000 per station.  And that is ridiculous, right? That is ridiculous. And also they rely on very legacy technology.  PLCs were built like 40 years ago. And that's also a major problem because this legacy technology was created at a time that internet didn't exist.  So they use unsecured protocols to communicate. Most companies rather patch their devices instead of redesign.  We are in a situation where we need redesign and they are closed source.  So this is a problem if you are a researcher and trying to figure out how they work.  So I came up with a solution. If you guys know about it, open PLC. That's my thing, right?  Open PLC is the world's first and only one PLC available with the full source code.  There are other approaches that people try to develop their own PLCs, but it is not closed to what a PLC should look like.  PLC, there are many standards that define what a PLC should do and how it should behave.  And I try to follow those standards close so that it will look like a real PLC and behave as much as possible to a real PLC.  And I make the source code available. Anyone can go take a look at the code and use it. It is free, right?  And basically open PLC has three main components. The runtime, that is the big thing that I am creating,  is the thing that goes into the embedded system, embedded device.  Initially I started creating my own hardware, but then I gave up and started using Raspberry Pi, Arduinos and stuff that everybody have.  So you can load the runtime on your embedded system and have it read your PLC programs.  You create your PLC programs on the editor that is supposed to run on your computer, right?  On your Windows, Linux, machine. Some folks have ported it to Mac OS as well.  And the third portion of it is KWR, which is a GUI builder that allows you to create nice animated graphical screens for your PLC programs, right?  So for the open PLC runtime, it runs on many different platforms.  These are the platforms that are currently supported, officially supported.  Like I said, Raspberry Pi, Arduinos, but also there are some industrial devices that people created that also runs open PLC, like UniPi and Pi Extend.  This is really cool. You can go and buy those devices and install open PLC today if you want.  There are other devices that are not here. They are not officially supported.  They were created by the community. So I have a forum with lots of people in there and they, you know, make all sorts of questions.  And they also contribute to the project and they created unofficial patches that make open PLC run on like Orange Pi and other platforms that basically run Linux.  This is the editor, what it looks like. It supports five programming languages.  These are all the five languages defined on the standard.  And this is KWBR, right? This is a real nice graphical screen created on KWBR.  So it can create many things. This is the water temperature control you're going to see today.  So let's go to talk about PLC protocols for a bit.  I don't know if you touched on SCADA protocols before, but what it looks like.  There are problems with those protocols. Basically, most protocols today are derived from legacy serial networks.  So if you're old enough, you might remember those RS485 networks where you hook up a bunch of devices on a serial cable and all the devices receive the same message and they decide if they want to accept it or not.  This is great for hacking, right?  You just listen to the bus and you get everything.  There is no authentication, of course. There is no integrity.  And when I mean integrity, I'm not talking about error correction.  I'm talking about if somebody tempers the message, is that going to be figured out at the other end or not?  So they don't have any integrity mechanisms.  And there is no confidentiality. So the message goes on the field with no confidentiality, which means it goes in plain text.  So the most popular SCADA protocol is Modbus.  It's about 90% of the PLCs support that.  Actually, I haven't found any PLC that does not support Modbus.  They usually support their own protocol plus something else plus Modbus.  Everybody talks Modbus.  And in essence, Modbus is very simple.  There's nothing very complicated with that.  It is, of course, based on serial networks.  And the commands, basically how it works is that the commands for the protocol are encoded into function codes.  So you have different function codes for different things you want to do.  And it's open.  That's probably why everybody supports Modbus because it doesn't require any licensing.  You can go and pay Modbus Foundation to have your device certified so that they make sure that your device is actually following the full standard.  But you don't have to do that to support the protocol.  There's no licensing, right?  Licensing fee.  And this is the Modbus frame.  That's what it looks like.  Basically, the first byte is a slave ID.  And the slave ID is a unique address because it was based on serial networks.  So you have to have a way to address a device.  The function code is what I was talking about.  It tells the slave device what to do.  It's like the command it should obey, right?  And the function code varies from reading or writing to memory areas.  Data.  Well, data is data, right?  It depends on the function code you're using.  And finally, CRC, it's just error correction verification.  Again, this is not checking integrity of the message itself.  It's just checking if there are any physical errors that happened on the transmission, right?  If somebody can tamper with this frame, change the data, recalculate CRC and send it through, it will go, right?  It will be accepted by the PLC.  So those are the most used function codes.  There is function codes to read digital outputs, to read digital inputs,  and also to read and write registers.  Basically, all it is is working with memory.  So Modbus gives you free access to the PLC memory.  You can read whatever you want.  You can write whatever you want with no authentication.  Who loves that, right?  They updated Modbus to make it compatible with TCP IP networks.  What it means is that they added a frame on top of the Modbus frame.  So basically, it has a transaction ID to keep track of all the transactions you're making.  So if the host makes a transaction, it makes a random number on that transaction ID.  So when it receives a response, it might receive a bunch of response from the same slave device.  And it will match the transaction ID to make sure that that response is related to the query it was making.  Protocol ID.  It seems that originally Modbus on TCP was meant to work with other protocols as well.  So they created this field so that different values on that field will mean different protocols.  I've never seen anybody using anything different than 00.  And 00 stands for Modbus.  So I think they field on this.  Length is length, right?  How many bytes there are after it.  And after that, it's just plain serial Modbus frame as it was before.  They kept the slave ID byte on that frame  because some people would just convert between TCP IP networks and serial networks.  So you have all devices talking serial and new devices talking TCP.  So keeping that byte over there means that serial devices will also be able to receive that message, right?  Even though if they are addressed on TCP.  For TCP only PLCs, usually that byte means nothing.  They will accept anything.  Tax scenarios.  What can we do with this?  So you can create a few different attacks on that.  Because the message is so simple, you can just interrupt the communication and cause a denial of service.  There are many ways to do that.  You can intercept the message and read the contents because there is no encryption.  No confidentiality at all.  You can also modify the message.  You get the message, you get a bump in the wire or some sort of either cap or poisoning hack.  And you get the message since it's plain text, you modify the contents, send it back.  Yeah, that is pretty disastrous.  And my favorite, injection.  You can only just send a freaking frame.  The PLC will accept you, right?  It accepts everybody.  So let's demo it.  Hopefully it will work.  So I have here skatobr.  And let me start the last PLC.  I didn't have the time to do it.  Hopefully I will now.  Let me get back to skatobr.  So this is skatobr for you to get familiar with it.  It's an old tool, but it works very well.  And I incorporated it into the Open PLC project so that we can update it and renovate it over time.  So here I have all my data sources.  These are all my PLCs.  So here on the table, I have three different PLCs.  The first one here is Open PLC running on a UniPy platform.  This is an industrial platform.  The second one is an Allen Bradley MicroLogix 1400 series.  And the third one is a Schneider modicon M221.  So let me go ahead and try to turn them all on.  Hopefully they are good.  So let me start this PLC as well.  In the meantime, while this thing is starting, let me show you the graphical screen and see how it looks like.  So this screen shows my system, my setup here.  So what I have, as I said before, I have a cup filled with water and a water heater element inside it and a temperature sensor.  The temperature sensor is connected to the PLC, so I have three identical setups.  And since PLC is all ladder logic, I just created the same ladder logic for all the three PLCs.  So they are running identical logic programs.  Of course, each architecture will just interpret that logic differently internally, right?  Some will compile that to binary code, that's in case for Open PLC.  Some will just convert that to virtual machine that will just run interpreted instructions.  So it varies by vendor, but they all, in essence, doing the same logic.  I just copy paste the same ladder diagram to make sure they are all running the same thing.  And on that configuration, I have a flexibility here that I can set the PLC for manual mode,  turn on the heater if I want manually so you can see the heater going up here.  Just a little break to turn on the PLC, sorry.  And I can turn the heater off.  I can put in auto mode.  So the auto mode will try to keep the temperature around 40 degrees Celsius,  and you know, temperature is a slow thing, so you might go up slowly and go down slowly.  But in essence, all the PLCs are trying to keep that around 40,  except this third little one because it's not on yet.  Sorry about that.  Let me just log in here, and in one second I will turn it on.  So my job here is try to attack these PLCs.  Once I am in the network, I will show you how easy it is to create a Modbus frame and attack it.  Right?  Last click. Not yet.  Okay, should be good to go.  Let me start it.  Yes, I want.  By the way, this is so machine basic.  This is the software used to program the Schneider Modicon M221.  We will have a lot of fun with that software today.  Okay, so let me start my terminal here.  So I have an injection attack ready.  What this injection attack does, it tries to send Modbus packets that will switch the PLCs in manual mode  and keep the heater on.  Right?  And this message will be sent over and over and over again,  so that the operator will lose control of the PLC and will not be able to turn it off.  Right?  So I will start the attack now.  This little attack, I hate sound.  This little attack has two parameters.  I created this software.  By the way, everything is available on Mykit Hub,  so if you want to get those tools, go ahead.  You have it.  So it has two parameters.  The first one is the host.  So the host is 100, 100, 100, 100, because I am really bad with numbers.  I had to choose a good one.  And the other parameter is frequency.  I won't use it.  The default frequency is 1,000 messages per second.  So let's try that on OpenPLC.  Go.  All right, cool.  Heater is on.  Let's turn it off.  Well, it doesn't work.  So let's put it out of mode.  It doesn't work either.  I'm screwed.  So that's probably what the operator will be thinking.  You see the temperature going up,  and you can do anything about it.  And all it takes is sending freaking Modbus frames.  That's all it takes.  What I'm doing here is writing to a portion of the memory of the PLC  that I know it's storing the setting for manual or auto mode  and the other area that is storing the setting for the heater if it's on or off.  That's all it takes.  And I can guarantee you that this kind of attack works with 100% of the PLC  that I know off.  Right?  So, okay, let's stop this because I have boiling water already.  Let me put back on auto mode.  We'll shut off the heater.  Now, let's try the same thing with our friend, Alan Bradley.  It is at the same IP except 101.  I know.  I'm bad with numbers.  So, let's try that again.  Boom.  Oh, gosh, no.  It's on.  It doesn't work.  Right?  Auto mode also does not work.  Temperature will go up.  And, yeah, it works the same way.  You see different brand of PLC, freaking same Modbus protocol.  That's the culprit.  Okay?  Let me stop this.  Auto mode again.  Last attack.  Let's try that on the Schneider modicon.  Please, misbehave.  Okay, it's on.  Even though the temperature is also over the set point, it does not work either.  Right?  So, that's how simple it is.  You can today start creating your own PLC attacks.  Okay, let me stop this.  Now, this was pretty fun.  And I had a lot of fun creating this, but I have one more thing.  For those of you who are a fan of Steve Jobs, this is where the best part happens, right?  So, let's talk about micrologics.  Micrologics is a PLC from Alan Bradley.  And Rocko Automation, I don't know the history, who bought who, but they keep both names in,  so I just say both names.  But what are the fun facts about micrologics 1400 series?  You should be buying one today to hack.  It's a pretty fun device.  Right?  So, first of all, it runs VXWorks.  VXWorks is one of the most popular real-time operating systems on the industry.  It's on everything, right?  Including PLCs.  And there are a bunch of vulnerabilities reported for that device.  Guess what?  I bet most of those works with Alan Bradley as well, right?  It is one of the most popular Alan Bradley PLC.  You see that everywhere.  And it supports Modbus DCP.  That's why the injection attack worked.  This is my favorite feature.  It can be killed remotely by sending a bad Modbus packet.  This is great.  So, let me talk about this, what I call micrologics deadly packets.  Basically, all it takes, it's to trick the memory allocation algorithm of the micrologics PLC.  So, what I do is I start a new transaction ID.  Protocol, of course, is Modbus00.  And on the length field, I say I will need 20, 256 bytes, right?  But I only have six.  All right?  So, it might try to allocate that much memory, but it's only receiving less than that.  And right immediately after, I start a new transaction ID where the length is the length of the previous packet.  And it's incomplete.  It stops at the unit ID.  So, it makes the PLC confused with this memory management system.  And I cause a buffer overflow, writing that message on a different area of the device, crashing the device and making it unrecoverable.  So, let's try to do that.  Okay.  All right.  So, just to check here, I should have everybody running.  Wow.  I laughed that PLC on for too long.  All right.  So, we're targeting Eileen Bradley now.  It should be working fine.  So, I'll just put in manual mode to prove like the heater is on, heater is off.  Everything should work beautifully.  Auto mode should keep the heater off.  Let me just keep that on heater on so that will be more fun.  So, let me go.  It's hard to type when your hands are shaking.  It should be Eileen Bradley exploit.  This is also available on my GitHub.  So, the only argument it takes is the IP address of the PLC.  So, all it does is send those two deadly packets and let's see what happens when I do it.  Dead.  So, you'll see right now that the PLC is not communicating anymore.  You see the exclamation point all around?  Ha, dead.  How cool is that, right?  You can even try to press the buttons over there.  It's completely dead.  And you know the fun fact of it is if you power cycle, it's still dead.  I'll prove it.  I just power cycled it.  And it will boot again.  It managed to boot again, but default LED keeps on for some reason.  So, yeah, it is booting up and you still see the exclamation points here.  Till the end of the presentation.  So, the problem is that application got corrupted so the PLC cannot launch it again.  The fault mode is always on.  The only way to make it work again is to reprogram it with the ladder logic.  This is creepy, right?  So, if you lost the ladder logic, you screwed.  Please don't send it on the wild.  There are too many micrologic PLCs out there.  All right, let's behave.  Okay, let me see if I have something else.  This is a problem that affects all MicroLogic's 1400 series.  I don't know about others because I'm not rich to buy all the PLCs,  but I bet it also affects some other related series like 1100 and so.  I talked to Alan Bradley through ICS-SERT.  We published this vulnerability and they are really nice.  They responded back and tried to work with me to create a patch.  So, they released recently about a few months ago a firmware update.  This firmware update fixes this vulnerability, although it's a pain to update it.  I spent like half an hour trying to do that and I'm supposed to be a security expert.  Imagine people out in the field what they will do to try to update this thing.  They won't stop their factory to update their PLC firmers.  Hopefully, the new PLCs that will be sold now will have this new update already built in.  There are other mitigations where please disable Modbus TCP.  This is not a fix.  Dude, if you're disabled in the protocol, you're not fixing it.  You're just disabling it.  This mentality is common for all the PLC vendors that I usually talk to.  Minimize network exposure, but PLC is behind a firewall.  Basically, what they're telling you is the security is on you.  We don't provide security.  You're freaking alone.  So, try to do your best.  These are good practices, but I honestly believe that a PLC, the device itself,  should provide any sort of security.  And one last thing.  All right.  Schneider.  There is a special reason why I brought the Schneider PLC with me.  The Schneider has a protocol that is common to all the Modicon family.  I think other families also use this.  It's called Unity Protocol.  At least me and some other researchers are working with this.  Call it Unity or UMAS.  You might hear both names.  And this protocol is obscure.  It is undocumented.  It runs on top of Modbus TCP, so you have a normal Modbus transaction.  But one, you have a function code 0x58.  This is exo decimal for 58.  This triggers the sub protocol that runs on the data field of the Modbus frame.  And for the Modbus documentation, 5a is a reserved function code  for specific vendor-specific functions.  And this is a nice part.  This protocol is used to configure and monitor the PLC.  Down to the operating system level, you can do a total memory dump using this protocol.  You can get the freaking operating system image using that.  So this is crazy, right?  It's proprietary and undocumented, so they try to make secure by obscurity,  but that won't prevent us from figuring that out how it works.  So basically, Unity have a bunch of function codes,  so it's a function code inside a function code.  You have the Modbus frame, and then you have the Unity frame.  And these are the function codes you can play with.  And I have to thank Luis Litas.  He is a researcher on the same field.  We started talking and communicating like one year ago,  because I figured out he was working on the Unity devices as well,  and we started contributing to each other.  And he has a very nice blog, LitasEnlarred.xyz.  You go, if you want, you can go and check it out.  He has a step-by-step how he managed to get those function codes  and reverse engineer the DLLs for the So Machine Basic and get that information.  So this is pretty cool.  And basically, you can take a look at some messages here.  They're pretty cool, like read memory block.  This is my favorite.  Okay, so, but today, given the time constraint,  we'll only play with a few of those.  So basically, we'll start a communication, init communication.  We'll read a project info to read some data about the project.  This is also cool.  Take PLC reservation.  It means that the PLC needs to be connected to someone.  Someone needs to reserve the PLC.  If you take the PLC reservation, you're taking the other party down.  This is DOS, built in the protocol, dudes.  This is what?  Right?  So you just keep sending this take PLC reservation,  and I think nobody else can connect.  So release PLC reservation, and you're releasing it  because you just don't want to communicate anymore.  And start PLC and stop PLC will,  basic main functions to start and stop the PLC.  All right.  So, let's play with it.  I'll just keep this slide open so we can play a little bit with how it works.  Is that up?  Okay.  So, I created also a little software, Modicon tester.  I don't remember the name of the executable.  Okay.  So, this software was created in C sharp in a hurry.  Please don't look at the code.  It's messy.  But the good thing is it works.  And all I did was to create this thing to help me reverse engineer the protocol.  So it basically encapsulates my messages on the Modbus frame with the function code 5a.  So I can send anything and it will be accepted as unity messages.  So, all you do, you connect to the PLC.  It's already set up with the M221 IP address.  I connect.  And then it gives me the exodesimal output and the ASCII related to that.  So let's start by starting our communication.  So every function code has two bytes, 0001, and I'll end it with 00.  So it just gave me back a hi.  I'm here.  That's fine.  Hello.  So let's go ahead and release PLC reservation.  If somebody was talking to it, sorry.  And then I'll take the reservation, 10, 00.  And now the take reservation is an interesting thing.  I don't know if you can see it.  Sorry.  I should have made it bigger.  But I'll promise I'll read it right.  The message is sending me back with the take PLC reservation.  It ends with a magic byte.  In this case, it's 8e.  It's even smaller for me.  So 8e, I mean, it's this magic byte that I need to send before any message that I want to send now on.  Now that I have a session, I have a reservation, I have reserved the PLC for me,  I'll have to use this magic byte.  That means that before, people were trying to do replay attacks.  So the replay attacks would be successful just because they didn't have any session management.  So you could just get messages that the main station was sending and just replay that and it would work.  Now you need the session number, but that won't prevent us from sending stuff.  Right?  So now let's play with this.  I have 8e as my session number.  You can see here, oh, urgent.  Alan Bradley is not talking, still.  Sorry.  Sorry, dude.  You can see that the modicon is still working fine.  Temperature is 40 degrees Celsius.  I can turn the heater on manually and off.  Right?  It works.  So what I'll do here, I will send a stop PLC command.  So I need to start with my 8e and then the stop message is 41.  It ends with ff00 and let's see.  Stopped.  Now the PLC can still communicate, but the heater is off.  I cannot turn it on.  I cannot turn it off.  I cannot put an auto or manual mode.  It's off.  How cool is that?  So just by sending a few messages, I can have full control of the PLC.  But here comes my favorite feature of this protocol.  This is really interesting.  So I'm going to use the So Machine Basic here for a second.  Let me just create something new.  So I'm just using their application to talk to this PLC over here.  Right?  And when I click here, it already identified my PLC, I try to log in and it's trying to log in.  But this application is password protected.  How come?  So I cannot access my PLC without the password.  If I try to type anything, it won't give me access.  Right?  All right.  What can we do about it?  Okay, let me get back to my Unity tester here.  So remember that message, read project info?  For some reason, that thing doesn't even require a session.  So I'll go ahead and send this.  00, no session.  03 is the function code for that and 00.  00 will just get the header.  So let's see what comes out of it.  My header for the project that is stored on the PLC.  And this is the name of the project.  What is this?  Yes, the freaking password.  Right?  So if I were Steve Jobs and I was working at Schneider, I would say this is not a buck, this is a feature.  What if you forgot the password?  The device needs to tell you that.  Right?  So let's try it.  Defcon is my password.  So when I type Defcon, boom, I mean, super hard.  Right?  Now I have full control of the PLC again using their own software just because I stole the password.  And it works.  I've tried with different, slightly different types of Modicon, M-something serious.  And the same thing works.  So, yeah, you can play with that.  I can start the controller because I stopped it before.  And I can see the programming on it.  Yeah, I have full access.  So this is pretty hilarious.  Now, that's to show you how secure your PLC is.  And imagine that those things are controlling your nuclear power plants and your water filtration systems.  I'll just go live in a jungle.  So, Schneider also, they were really nice.  I submitted this through ICS cert and they talk with me and we try to come up with some mitigations.  And they recommended the following things.  Disable unity protocol.  This is the best mitigation ever.  So again, you see a different vendor with the same mentality.  Just turn that freaking thing off.  It doesn't work.  Right?  They also recommended, because of that password vulnerability and all of that,  they recommended to store your project files in secure, access restricted locations,  and encrypt your project files with reputable third party file encryption tools.  Again, they're giving you the responsibility to fix stuff, to secure your settings.  And this is pretty, it gets me worried.  Right?  And a little bit about what I plan to do in the future.  By the way, I haven't showed you this.  This is what Open PLC looks like.  This is a web interface that is running on the device.  So once you install the runtime, you have that interface up and you can see your programs.  You can see your hardware.  You can even mess up with the code live.  Right?  So it's pretty cool.  And this thing is also vulnerable and insecure.  I created it to be like that because I'm trying to mimic what other vendors are doing.  So we can kind of research about it.  But my PhD thesis is about creating a secure version of Open PLC that will try to prevent those types of attacks from happening.  Okay?  So it was really fun to be here at DefCon today.  It was really an honor to me to be here.  And thank you very much for coming and staying with me this Saturday morning.  If anybody have any questions?
DEF_CON_26_-_Thiago_Alves_-_Hacking_PLCs_and_Causing_Havoc_on_Critical_Infrastructures_-KHel7SyXsU_0_311.png DEF_CON_26_-_Thiago_Alves_-_Hacking_PLCs_and_Causing_Havoc_on_Critical_Infrastructures_-KHel7SyXsU_312_359.png DEF_CON_26_-_Thiago_Alves_-_Hacking_PLCs_and_Causing_Havoc_on_Critical_Infrastructures_-KHel7SyXsU_360_407.png DEF_CON_26_-_Thiago_Alves_-_Hacking_PLCs_and_Causing_Havoc_on_Critical_Infrastructures_-KHel7SyXsU_408_575.png DEF_CON_26_-_Thiago_Alves_-_Hacking_PLCs_and_Causing_Havoc_on_Critical_Infrastructures_-KHel7SyXsU_576_623.png DEF_CON_26_-_Thiago_Alves_-_Hacking_PLCs_and_Causing_Havoc_on_Critical_Infrastructures_-KHel7SyXsU_624_671.png DEF_CON_26_-_Thiago_Alves_-_Hacking_PLCs_and_Causing_Havoc_on_Critical_Infrastructures_-KHel7SyXsU_672_755.png DEF_CON_26_-_Thiago_Alves_-_Hacking_PLCs_and_Causing_Havoc_on_Critical_Infrastructures_-KHel7SyXsU_756_5339.png DEF_CON_26_-_Thiago_Alves_-_Hacking_PLCs_and_Causing_Havoc_on_Critical_Infrastructures_-KHel7SyXsU_5340_6431.png DEF_CON_26_-_Thiago_Alves_-_Hacking_PLCs_and_Causing_Havoc_on_Critical_Infrastructures_-KHel7SyXsU_6432_11135.png DEF_CON_26_-_Thiago_Alves_-_Hacking_PLCs_and_Causing_Havoc_on_Critical_Infrastructures_-KHel7SyXsU_11136_12839.png DEF_CON_26_-_Thiago_Alves_-_Hacking_PLCs_and_Causing_Havoc_on_Critical_Infrastructures_-KHel7SyXsU_12840_21899.png DEF_CON_26_-_Thiago_Alves_-_Hacking_PLCs_and_Causing_Havoc_on_Critical_Infrastructures_-KHel7SyXsU_21900_21959.png DEF_CON_26_-_Thiago_Alves_-_Hacking_PLCs_and_Causing_Havoc_on_Critical_Infrastructures_-KHel7SyXsU_21960_23051.png DEF_CON_26_-_Thiago_Alves_-_Hacking_PLCs_and_Causing_Havoc_on_Critical_Infrastructures_-KHel7SyXsU_23052_26411.png DEF_CON_26_-_Thiago_Alves_-_Hacking_PLCs_and_Causing_Havoc_on_Critical_Infrastructures_-KHel7SyXsU_26412_26471.png DEF_CON_26_-_Thiago_Alves_-_Hacking_PLCs_and_Causing_Havoc_on_Critical_Infrastructures_-KHel7SyXsU_26472_32363.png DEF_CON_26_-_Thiago_Alves_-_Hacking_PLCs_and_Causing_Havoc_on_Critical_Infrastructures_-KHel7SyXsU_32364_32459.png DEF_CON_26_-_Thiago_Alves_-_Hacking_PLCs_and_Causing_Havoc_on_Critical_Infrastructures_-KHel7SyXsU_32460_36119.png DEF_CON_26_-_Thiago_Alves_-_Hacking_PLCs_and_Causing_Havoc_on_Critical_Infrastructures_-KHel7SyXsU_36120_36179.png DEF_CON_26_-_Thiago_Alves_-_Hacking_PLCs_and_Causing_Havoc_on_Critical_Infrastructures_-KHel7SyXsU_36180_36227.png DEF_CON_26_-_Thiago_Alves_-_Hacking_PLCs_and_Causing_Havoc_on_Critical_Infrastructures_-KHel7SyXsU_36228_36299.png DEF_CON_26_-_Thiago_Alves_-_Hacking_PLCs_and_Causing_Havoc_on_Critical_Infrastructures_-KHel7SyXsU_36300_39839.png DEF_CON_26_-_Thiago_Alves_-_Hacking_PLCs_and_Causing_Havoc_on_Critical_Infrastructures_-KHel7SyXsU_39840_39935.png DEF_CON_26_-_Thiago_Alves_-_Hacking_PLCs_and_Causing_Havoc_on_Critical_Infrastructures_-KHel7SyXsU_39936_40019.png DEF_CON_26_-_Thiago_Alves_-_Hacking_PLCs_and_Causing_Havoc_on_Critical_Infrastructures_-KHel7SyXsU_40020_42491.png DEF_CON_26_-_Thiago_Alves_-_Hacking_PLCs_and_Causing_Havoc_on_Critical_Infrastructures_-KHel7SyXsU_42492_42599.png DEF_CON_26_-_Thiago_Alves_-_Hacking_PLCs_and_Causing_Havoc_on_Critical_Infrastructures_-KHel7SyXsU_42600_48023.png DEF_CON_26_-_Thiago_Alves_-_Hacking_PLCs_and_Causing_Havoc_on_Critical_Infrastructures_-KHel7SyXsU_48024_53507.png DEF_CON_26_-_Thiago_Alves_-_Hacking_PLCs_and_Causing_Havoc_on_Critical_Infrastructures_-KHel7SyXsU_53508_57095.png DEF_CON_26_-_Thiago_Alves_-_Hacking_PLCs_and_Causing_Havoc_on_Critical_Infrastructures_-KHel7SyXsU_57096_57203.png DEF_CON_26_-_Thiago_Alves_-_Hacking_PLCs_and_Causing_Havoc_on_Critical_Infrastructures_-KHel7SyXsU_57204_57467.png DEF_CON_26_-_Thiago_Alves_-_Hacking_PLCs_and_Causing_Havoc_on_Critical_Infrastructures_-KHel7SyXsU_57468_59015.png DEF_CON_26_-_Thiago_Alves_-_Hacking_PLCs_and_Causing_Havoc_on_Critical_Infrastructures_-KHel7SyXsU_59016_59099.png DEF_CON_26_-_Thiago_Alves_-_Hacking_PLCs_and_Causing_Havoc_on_Critical_Infrastructures_-KHel7SyXsU_59100_59363.png DEF_CON_26_-_Thiago_Alves_-_Hacking_PLCs_and_Causing_Havoc_on_Critical_Infrastructures_-KHel7SyXsU_59364_60095.png DEF_CON_26_-_Thiago_Alves_-_Hacking_PLCs_and_Causing_Havoc_on_Critical_Infrastructures_-KHel7SyXsU_60096_60191.png DEF_CON_26_-_Thiago_Alves_-_Hacking_PLCs_and_Causing_Havoc_on_Critical_Infrastructures_-KHel7SyXsU_60192_60383.png DEF_CON_26_-_Thiago_Alves_-_Hacking_PLCs_and_Causing_Havoc_on_Critical_Infrastructures_-KHel7SyXsU_60384_60710.png
Alright, it's about that time to get the show on the road. So everyone please give a very warm welcome to Chiyago who will be talking about hacking PLCs. Sorry I have a little experiment here. It took a little longer to set up than I was expecting. But I am very very happy to be here at DEF CON today and I was honestly expecting like 50 maybe 100 people. So thank you guys for taking the time to be here on Saturday morning and listen to me. I am Chiyago Alves and a little bit about me. I am a PhD student at UAH and I also work at the center for Cybersecurity Research and Education. It's called CCRE at the university. And yes, this is what I do. I love to hack stuff and I try to break as many things as I can. And I'm also the creator of the Open PLC project. If you guys haven't heard of it, you'll hear about it a little bit today. So heads up if somebody has heard about Open PLC before. Wow, thank you. That's great. That's great. Thank you. Also today, it's a very important day for me because this trip to Vegas marks our ninth year anniversary. Me and my wife were together for 90 years and yeah, I used to have more hair back then but she's still pretty the same way. So I'm a lucky guy. And she always complained about being like slowing me down because now we have kids and I have other things to focus on. But I keep telling her that if you want to go fast, you go alone. Life is not about speed. But if you want to go further, if you want to go far, you go together. That's why I'm here. That's because of you. Right? And I'm very happy. I invited her to be here at my talk. Thank you. And she has a very important job actually because I have really bad jokes and she laughs of all of them. So if you hear her laughing, just please laugh as well. So we have a nice presentation. Okay? Okay. So a little outline about today. I'm going to start with a background info. You know a little bit about PLCs. If you guys know about PLCs, I'll try to go fast. If you don't know about PLCs, please pay attention because I will go fast. Okay. Then we'll go and talk about a little attack vectors, some stuff we can do to break those things. And finally we'll demo. If the demo demons haven't gotten me because I didn't have enough time to set up. So hopefully things will go out fine. So what is a PLC after all? It is, that's what it looks like. Right? It's a brick. And it stands for Programmable Logic Controller. And basically it's a digital computer. It's used on automation since 1970. So it's a long time ago. And basically it is an embedded system with a CPU, some RAM, some ROM, some flash nowadays. And you put your program in there, you run your program. And your program decides what to do with the input data it senses from the input modules the PLC has. So PLC has a bunch of inputs, a bunch of outputs. I have three PLCs set it up here trying to heat water. And they're doing a poor job doing that. But then you program those devices to any logic you want. And it has output modules to control real life stuff. Right? So for example in this setup it's controlling the heater based on the temperature sensor that is attached to the input module. And you will see PLCs in many different places. So here I have like a dam, a substation, a gas distribution system in a petrochemical facility. And PLCs are there. And you imagine what happens if you hack into those PLCs and make a crash, right? Or change a setting. So for all those situations a disaster will follow if you break into a PLC. Because they are controlling large, huge stuff that can cause even physical damage and life loss, right? So what is the problem with the current PLCs we have? First of all, they are freaking expensive. You know, if you're building an embedded system it shouldn't cost that much. Nowadays there are some companies selling what they call cheapo PLCs. You can buy one for like 100 or 200 dollars. But then they get you on software. There are companies selling software, programming software for PLCs for up to $5,000 per station. And that is ridiculous, right? That is ridiculous. And also they rely on very legacy technology. PLCs were built like 40 years ago. And that's also a major problem because this legacy technology was created at a time that internet didn't exist. So they use unsecured protocols to communicate. Most companies rather patch their devices instead of redesign. We are in a situation where we need redesign and they are closed source. So this is a problem if you are a researcher and trying to figure out how they work. So I came up with a solution. If you guys know about it, open PLC. That's my thing, right? Open PLC is the world's first and only one PLC available with the full source code. There are other approaches that people try to develop their own PLCs, but it is not closed to what a PLC should look like. PLC, there are many standards that define what a PLC should do and how it should behave. And I try to follow those standards close so that it will look like a real PLC and behave as much as possible to a real PLC. And I make the source code available. Anyone can go take a look at the code and use it. It is free, right? And basically open PLC has three main components. The runtime, that is the big thing that I am creating, is the thing that goes into the embedded system, embedded device. Initially I started creating my own hardware, but then I gave up and started using Raspberry Pi, Arduinos and stuff that everybody have. So you can load the runtime on your embedded system and have it read your PLC programs. You create your PLC programs on the editor that is supposed to run on your computer, right? On your Windows, Linux, machine. Some folks have ported it to Mac OS as well. And the third portion of it is KWR, which is a GUI builder that allows you to create nice animated graphical screens for your PLC programs, right? So for the open PLC runtime, it runs on many different platforms. These are the platforms that are currently supported, officially supported. Like I said, Raspberry Pi, Arduinos, but also there are some industrial devices that people created that also runs open PLC, like UniPi and Pi Extend. This is really cool. You can go and buy those devices and install open PLC today if you want. There are other devices that are not here. They are not officially supported. They were created by the community. So I have a forum with lots of people in there and they, you know, make all sorts of questions. And they also contribute to the project and they created unofficial patches that make open PLC run on like Orange Pi and other platforms that basically run Linux. This is the editor, what it looks like. It supports five programming languages. These are all the five languages defined on the standard. And this is KWBR, right? This is a real nice graphical screen created on KWBR. So it can create many things. This is the water temperature control you're going to see today. So let's go to talk about PLC protocols for a bit. I don't know if you touched on SCADA protocols before, but what it looks like. There are problems with those protocols. Basically, most protocols today are derived from legacy serial networks. So if you're old enough, you might remember those RS485 networks where you hook up a bunch of devices on a serial cable and all the devices receive the same message and they decide if they want to accept it or not. This is great for hacking, right? You just listen to the bus and you get everything. There is no authentication, of course. There is no integrity. And when I mean integrity, I'm not talking about error correction. I'm talking about if somebody tempers the message, is that going to be figured out at the other end or not? So they don't have any integrity mechanisms. And there is no confidentiality. So the message goes on the field with no confidentiality, which means it goes in plain text. So the most popular SCADA protocol is Modbus. It's about 90% of the PLCs support that. Actually, I haven't found any PLC that does not support Modbus. They usually support their own protocol plus something else plus Modbus. Everybody talks Modbus. And in essence, Modbus is very simple. There's nothing very complicated with that. It is, of course, based on serial networks. And the commands, basically how it works is that the commands for the protocol are encoded into function codes. So you have different function codes for different things you want to do. And it's open. That's probably why everybody supports Modbus because it doesn't require any licensing. You can go and pay Modbus Foundation to have your device certified so that they make sure that your device is actually following the full standard. But you don't have to do that to support the protocol. There's no licensing, right? Licensing fee. And this is the Modbus frame. That's what it looks like. Basically, the first byte is a slave ID. And the slave ID is a unique address because it was based on serial networks. So you have to have a way to address a device. The function code is what I was talking about. It tells the slave device what to do. It's like the command it should obey, right? And the function code varies from reading or writing to memory areas. Data. Well, data is data, right? It depends on the function code you're using. And finally, CRC, it's just error correction verification. Again, this is not checking integrity of the message itself. It's just checking if there are any physical errors that happened on the transmission, right? If somebody can tamper with this frame, change the data, recalculate CRC and send it through, it will go, right? It will be accepted by the PLC. So those are the most used function codes. There is function codes to read digital outputs, to read digital inputs, and also to read and write registers. Basically, all it is is working with memory. So Modbus gives you free access to the PLC memory. You can read whatever you want. You can write whatever you want with no authentication. Who loves that, right? They updated Modbus to make it compatible with TCP IP networks. What it means is that they added a frame on top of the Modbus frame. So basically, it has a transaction ID to keep track of all the transactions you're making. So if the host makes a transaction, it makes a random number on that transaction ID. So when it receives a response, it might receive a bunch of response from the same slave device. And it will match the transaction ID to make sure that that response is related to the query it was making. Protocol ID. It seems that originally Modbus on TCP was meant to work with other protocols as well. So they created this field so that different values on that field will mean different protocols. I've never seen anybody using anything different than 00. And 00 stands for Modbus. So I think they field on this. Length is length, right? How many bytes there are after it. And after that, it's just plain serial Modbus frame as it was before. They kept the slave ID byte on that frame because some people would just convert between TCP IP networks and serial networks. So you have all devices talking serial and new devices talking TCP. So keeping that byte over there means that serial devices will also be able to receive that message, right? Even though if they are addressed on TCP. For TCP only PLCs, usually that byte means nothing. They will accept anything. Tax scenarios. What can we do with this? So you can create a few different attacks on that. Because the message is so simple, you can just interrupt the communication and cause a denial of service. There are many ways to do that. You can intercept the message and read the contents because there is no encryption. No confidentiality at all. You can also modify the message. You get the message, you get a bump in the wire or some sort of either cap or poisoning hack. And you get the message since it's plain text, you modify the contents, send it back. Yeah, that is pretty disastrous. And my favorite, injection. You can only just send a freaking frame. The PLC will accept you, right? It accepts everybody. So let's demo it. Hopefully it will work. So I have here skatobr. And let me start the last PLC. I didn't have the time to do it. Hopefully I will now. Let me get back to skatobr. So this is skatobr for you to get familiar with it. It's an old tool, but it works very well. And I incorporated it into the Open PLC project so that we can update it and renovate it over time. So here I have all my data sources. These are all my PLCs. So here on the table, I have three different PLCs. The first one here is Open PLC running on a UniPy platform. This is an industrial platform. The second one is an Allen Bradley MicroLogix 1400 series. And the third one is a Schneider modicon M221. So let me go ahead and try to turn them all on. Hopefully they are good. So let me start this PLC as well. In the meantime, while this thing is starting, let me show you the graphical screen and see how it looks like. So this screen shows my system, my setup here. So what I have, as I said before, I have a cup filled with water and a water heater element inside it and a temperature sensor. The temperature sensor is connected to the PLC, so I have three identical setups. And since PLC is all ladder logic, I just created the same ladder logic for all the three PLCs. So they are running identical logic programs. Of course, each architecture will just interpret that logic differently internally, right? Some will compile that to binary code, that's in case for Open PLC. Some will just convert that to virtual machine that will just run interpreted instructions. So it varies by vendor, but they all, in essence, doing the same logic. I just copy paste the same ladder diagram to make sure they are all running the same thing. And on that configuration, I have a flexibility here that I can set the PLC for manual mode, turn on the heater if I want manually so you can see the heater going up here. Just a little break to turn on the PLC, sorry. And I can turn the heater off. I can put in auto mode. So the auto mode will try to keep the temperature around 40 degrees Celsius, and you know, temperature is a slow thing, so you might go up slowly and go down slowly. But in essence, all the PLCs are trying to keep that around 40, except this third little one because it's not on yet. Sorry about that. Let me just log in here, and in one second I will turn it on. So my job here is try to attack these PLCs. Once I am in the network, I will show you how easy it is to create a Modbus frame and attack it. Right? Last click. Not yet. Okay, should be good to go. Let me start it. Yes, I want. By the way, this is so machine basic. This is the software used to program the Schneider Modicon M221. We will have a lot of fun with that software today. Okay, so let me start my terminal here. So I have an injection attack ready. What this injection attack does, it tries to send Modbus packets that will switch the PLCs in manual mode and keep the heater on. Right? And this message will be sent over and over and over again, so that the operator will lose control of the PLC and will not be able to turn it off. Right? So I will start the attack now. This little attack, I hate sound. This little attack has two parameters. I created this software. By the way, everything is available on Mykit Hub, so if you want to get those tools, go ahead. You have it. So it has two parameters. The first one is the host. So the host is 100, 100, 100, 100, because I am really bad with numbers. I had to choose a good one. And the other parameter is frequency. I won't use it. The default frequency is 1,000 messages per second. So let's try that on OpenPLC. Go. All right, cool. Heater is on. Let's turn it off. Well, it doesn't work. So let's put it out of mode. It doesn't work either. I'm screwed. So that's probably what the operator will be thinking. You see the temperature going up, and you can do anything about it. And all it takes is sending freaking Modbus frames. That's all it takes. What I'm doing here is writing to a portion of the memory of the PLC that I know it's storing the setting for manual or auto mode and the other area that is storing the setting for the heater if it's on or off. That's all it takes. And I can guarantee you that this kind of attack works with 100% of the PLC that I know off. Right? So, okay, let's stop this because I have boiling water already. Let me put back on auto mode. We'll shut off the heater. Now, let's try the same thing with our friend, Alan Bradley. It is at the same IP except 101. I know. I'm bad with numbers. So, let's try that again. Boom. Oh, gosh, no. It's on. It doesn't work. Right? Auto mode also does not work. Temperature will go up. And, yeah, it works the same way. You see different brand of PLC, freaking same Modbus protocol. That's the culprit. Okay? Let me stop this. Auto mode again. Last attack. Let's try that on the Schneider modicon. Please, misbehave. Okay, it's on. Even though the temperature is also over the set point, it does not work either. Right? So, that's how simple it is. You can today start creating your own PLC attacks. Okay, let me stop this. Now, this was pretty fun. And I had a lot of fun creating this, but I have one more thing. For those of you who are a fan of Steve Jobs, this is where the best part happens, right? So, let's talk about micrologics. Micrologics is a PLC from Alan Bradley. And Rocko Automation, I don't know the history, who bought who, but they keep both names in, so I just say both names. But what are the fun facts about micrologics 1400 series? You should be buying one today to hack. It's a pretty fun device. Right? So, first of all, it runs VXWorks. VXWorks is one of the most popular real-time operating systems on the industry. It's on everything, right? Including PLCs. And there are a bunch of vulnerabilities reported for that device. Guess what? I bet most of those works with Alan Bradley as well, right? It is one of the most popular Alan Bradley PLC. You see that everywhere. And it supports Modbus DCP. That's why the injection attack worked. This is my favorite feature. It can be killed remotely by sending a bad Modbus packet. This is great. So, let me talk about this, what I call micrologics deadly packets. Basically, all it takes, it's to trick the memory allocation algorithm of the micrologics PLC. So, what I do is I start a new transaction ID. Protocol, of course, is Modbus00. And on the length field, I say I will need 20, 256 bytes, right? But I only have six. All right? So, it might try to allocate that much memory, but it's only receiving less than that. And right immediately after, I start a new transaction ID where the length is the length of the previous packet. And it's incomplete. It stops at the unit ID. So, it makes the PLC confused with this memory management system. And I cause a buffer overflow, writing that message on a different area of the device, crashing the device and making it unrecoverable. So, let's try to do that. Okay. All right. So, just to check here, I should have everybody running. Wow. I laughed that PLC on for too long. All right. So, we're targeting Eileen Bradley now. It should be working fine. So, I'll just put in manual mode to prove like the heater is on, heater is off. Everything should work beautifully. Auto mode should keep the heater off. Let me just keep that on heater on so that will be more fun. So, let me go. It's hard to type when your hands are shaking. It should be Eileen Bradley exploit. This is also available on my GitHub. So, the only argument it takes is the IP address of the PLC. So, all it does is send those two deadly packets and let's see what happens when I do it. Dead. So, you'll see right now that the PLC is not communicating anymore. You see the exclamation point all around? Ha, dead. How cool is that, right? You can even try to press the buttons over there. It's completely dead. And you know the fun fact of it is if you power cycle, it's still dead. I'll prove it. I just power cycled it. And it will boot again. It managed to boot again, but default LED keeps on for some reason. So, yeah, it is booting up and you still see the exclamation points here. Till the end of the presentation. So, the problem is that application got corrupted so the PLC cannot launch it again. The fault mode is always on. The only way to make it work again is to reprogram it with the ladder logic. This is creepy, right? So, if you lost the ladder logic, you screwed. Please don't send it on the wild. There are too many micrologic PLCs out there. All right, let's behave. Okay, let me see if I have something else. This is a problem that affects all MicroLogic's 1400 series. I don't know about others because I'm not rich to buy all the PLCs, but I bet it also affects some other related series like 1100 and so. I talked to Alan Bradley through ICS-SERT. We published this vulnerability and they are really nice. They responded back and tried to work with me to create a patch. So, they released recently about a few months ago a firmware update. This firmware update fixes this vulnerability, although it's a pain to update it. I spent like half an hour trying to do that and I'm supposed to be a security expert. Imagine people out in the field what they will do to try to update this thing. They won't stop their factory to update their PLC firmers. Hopefully, the new PLCs that will be sold now will have this new update already built in. There are other mitigations where please disable Modbus TCP. This is not a fix. Dude, if you're disabled in the protocol, you're not fixing it. You're just disabling it. This mentality is common for all the PLC vendors that I usually talk to. Minimize network exposure, but PLC is behind a firewall. Basically, what they're telling you is the security is on you. We don't provide security. You're freaking alone. So, try to do your best. These are good practices, but I honestly believe that a PLC, the device itself, should provide any sort of security. And one last thing. All right. Schneider. There is a special reason why I brought the Schneider PLC with me. The Schneider has a protocol that is common to all the Modicon family. I think other families also use this. It's called Unity Protocol. At least me and some other researchers are working with this. Call it Unity or UMAS. You might hear both names. And this protocol is obscure. It is undocumented. It runs on top of Modbus TCP, so you have a normal Modbus transaction. But one, you have a function code 0x58. This is exo decimal for 58. This triggers the sub protocol that runs on the data field of the Modbus frame. And for the Modbus documentation, 5a is a reserved function code for specific vendor-specific functions. And this is a nice part. This protocol is used to configure and monitor the PLC. Down to the operating system level, you can do a total memory dump using this protocol. You can get the freaking operating system image using that. So this is crazy, right? It's proprietary and undocumented, so they try to make secure by obscurity, but that won't prevent us from figuring that out how it works. So basically, Unity have a bunch of function codes, so it's a function code inside a function code. You have the Modbus frame, and then you have the Unity frame. And these are the function codes you can play with. And I have to thank Luis Litas. He is a researcher on the same field. We started talking and communicating like one year ago, because I figured out he was working on the Unity devices as well, and we started contributing to each other. And he has a very nice blog, LitasEnlarred.xyz. You go, if you want, you can go and check it out. He has a step-by-step how he managed to get those function codes and reverse engineer the DLLs for the So Machine Basic and get that information. So this is pretty cool. And basically, you can take a look at some messages here. They're pretty cool, like read memory block. This is my favorite. Okay, so, but today, given the time constraint, we'll only play with a few of those. So basically, we'll start a communication, init communication. We'll read a project info to read some data about the project. This is also cool. Take PLC reservation. It means that the PLC needs to be connected to someone. Someone needs to reserve the PLC. If you take the PLC reservation, you're taking the other party down. This is DOS, built in the protocol, dudes. This is what? Right? So you just keep sending this take PLC reservation, and I think nobody else can connect. So release PLC reservation, and you're releasing it because you just don't want to communicate anymore. And start PLC and stop PLC will, basic main functions to start and stop the PLC. All right. So, let's play with it. I'll just keep this slide open so we can play a little bit with how it works. Is that up? Okay. So, I created also a little software, Modicon tester. I don't remember the name of the executable. Okay. So, this software was created in C sharp in a hurry. Please don't look at the code. It's messy. But the good thing is it works. And all I did was to create this thing to help me reverse engineer the protocol. So it basically encapsulates my messages on the Modbus frame with the function code 5a. So I can send anything and it will be accepted as unity messages. So, all you do, you connect to the PLC. It's already set up with the M221 IP address. I connect. And then it gives me the exodesimal output and the ASCII related to that. So let's start by starting our communication. So every function code has two bytes, 0001, and I'll end it with 00. So it just gave me back a hi. I'm here. That's fine. Hello. So let's go ahead and release PLC reservation. If somebody was talking to it, sorry. And then I'll take the reservation, 10, 00. And now the take reservation is an interesting thing. I don't know if you can see it. Sorry. I should have made it bigger. But I'll promise I'll read it right. The message is sending me back with the take PLC reservation. It ends with a magic byte. In this case, it's 8e. It's even smaller for me. So 8e, I mean, it's this magic byte that I need to send before any message that I want to send now on. Now that I have a session, I have a reservation, I have reserved the PLC for me, I'll have to use this magic byte. That means that before, people were trying to do replay attacks. So the replay attacks would be successful just because they didn't have any session management. So you could just get messages that the main station was sending and just replay that and it would work. Now you need the session number, but that won't prevent us from sending stuff. Right? So now let's play with this. I have 8e as my session number. You can see here, oh, urgent. Alan Bradley is not talking, still. Sorry. Sorry, dude. You can see that the modicon is still working fine. Temperature is 40 degrees Celsius. I can turn the heater on manually and off. Right? It works. So what I'll do here, I will send a stop PLC command. So I need to start with my 8e and then the stop message is 41. It ends with ff00 and let's see. Stopped. Now the PLC can still communicate, but the heater is off. I cannot turn it on. I cannot turn it off. I cannot put an auto or manual mode. It's off. How cool is that? So just by sending a few messages, I can have full control of the PLC. But here comes my favorite feature of this protocol. This is really interesting. So I'm going to use the So Machine Basic here for a second. Let me just create something new. So I'm just using their application to talk to this PLC over here. Right? And when I click here, it already identified my PLC, I try to log in and it's trying to log in. But this application is password protected. How come? So I cannot access my PLC without the password. If I try to type anything, it won't give me access. Right? All right. What can we do about it? Okay, let me get back to my Unity tester here. So remember that message, read project info? For some reason, that thing doesn't even require a session. So I'll go ahead and send this. 00, no session. 03 is the function code for that and 00. 00 will just get the header. So let's see what comes out of it. My header for the project that is stored on the PLC. And this is the name of the project. What is this? Yes, the freaking password. Right? So if I were Steve Jobs and I was working at Schneider, I would say this is not a buck, this is a feature. What if you forgot the password? The device needs to tell you that. Right? So let's try it. Defcon is my password. So when I type Defcon, boom, I mean, super hard. Right? Now I have full control of the PLC again using their own software just because I stole the password. And it works. I've tried with different, slightly different types of Modicon, M-something serious. And the same thing works. So, yeah, you can play with that. I can start the controller because I stopped it before. And I can see the programming on it. Yeah, I have full access. So this is pretty hilarious. Now, that's to show you how secure your PLC is. And imagine that those things are controlling your nuclear power plants and your water filtration systems. I'll just go live in a jungle. So, Schneider also, they were really nice. I submitted this through ICS cert and they talk with me and we try to come up with some mitigations. And they recommended the following things. Disable unity protocol. This is the best mitigation ever. So again, you see a different vendor with the same mentality. Just turn that freaking thing off. It doesn't work. Right? They also recommended, because of that password vulnerability and all of that, they recommended to store your project files in secure, access restricted locations, and encrypt your project files with reputable third party file encryption tools. Again, they're giving you the responsibility to fix stuff, to secure your settings. And this is pretty, it gets me worried. Right? And a little bit about what I plan to do in the future. By the way, I haven't showed you this. This is what Open PLC looks like. This is a web interface that is running on the device. So once you install the runtime, you have that interface up and you can see your programs. You can see your hardware. You can even mess up with the code live. Right? So it's pretty cool. And this thing is also vulnerable and insecure. I created it to be like that because I'm trying to mimic what other vendors are doing. So we can kind of research about it. But my PhD thesis is about creating a secure version of Open PLC that will try to prevent those types of attacks from happening. Okay? So it was really fun to be here at DefCon today. It was really an honor to me to be here. And thank you very much for coming and staying with me this Saturday morning. If anybody have any questions?
we'll go and talk about a little attack vectors, finally we'll demo. If the demo demons haven't for Programmable Logic Controller. And basically it's a digital computer. It's used on automation technology. PLCs were built like 40 years ago. Arduinos, but also there are some industrial other devices that are not here. They are not an Allen Bradley MicroLogix 1400 series. And the architecture will just interpret that logic the network, I will show you how easy it is to program the Schneider Modicon M221. We will have heater on. Right? And this message will be sent PLCs. And there are a bunch of vulnerabilities on a different area of the device, crashing the if you can see it. Sorry. I should have made it PLC, I try to log in and it's trying to log in. power plants and your water filtration systems. attacks from happening. Okay? So it was really