 So we all are in for a treat today. He's about to go give his talk on evil PLC's attacks. And I'll let you take it away. Thank you. Thank you, thank you very much. So I just make sure everything works. Looks like it. OK, we're ready to go. So hi, everyone. Today I'm going to talk about our cool research, evil PLC attack. And I'm going to show you how we were able to weaponize PLC's, programmable logic controllers. So let's start. I'm Shavant Brzezinov. I work as a vulnerability researcher at Clarity. We're doing a lot of ICS and SCADA security research. I'm a CTF player. I've played in a couple of CTFs, including Pound2Own, Miami 22 and 20. I also own a DEF CON Black Badge for winning the ICS CTF. And I'm mostly enjoying breaking PLC's. And I'm not sure if you can see in the small picture. This is our cool lab in Tel Aviv. Special thanks to my colleagues who worked on this research with me, Mashav, Uri, Nam, and Amir. Thank you very much. OK, so the agenda for today is to give you a little bit background and motivation for this research, why we started it. We're going to talk about PLC upload and download procedures. This is how we're transferring logic to the PLC so it could execute it and control the physical process. And finally, I'm going to introduce the evil PLC attack. This is a concept we have developed to weaponize PLC's so we could propagate and attack engineers and technicians. So let's start with the story time. So as I told you already, we have a super cool lab with a lot of ICS equipment in Tel Aviv. And around two years ago, we were like, yeah, we have a cool lab. Why won't we expose a couple of PLC's online so people could scan us and we will monitor the interaction because why not? So indeed, we chose a couple of PLC's from our lab. For example, what used to be GE now, it's Emerson RX3i. These are all controllers, industrial controllers. And we just plugged them to our external router and we exposed them online. We obviously monitored this entire experiment. We had sniffers and we had auditing and logs. And we waited a couple of weeks to see what happens. I bet you can guess that we've been hacked. But our honeypots, the real honeypots, were hacked OT style. Now what does it mean to hack OT style? So it means a bunch of script kids used showdown to scan the internet and then they just use the commercial engineering work station. This is the software that the vendors are distributing along size with the hardware to program and monitor the PLC's. So basically it's kind of a diagnostic tool and IDE to program the PLC. So all these sophisticated attackers did was to use this software plugged in the IP they got probably on showdown or census. And what they did is they changed our logic using the engineering work station. Now how did they do that? They used two main functionalities. So the first functionality they used is called upload procedure. In upload procedure, you're asking the PLC, the engineering work station software asks the PLC, hey, what's currently running on the PLC? So it asked to transfer the logic from the PLC to the application, which is usually Windows-based. So we could see in our engineering work station what is currently running on the PLC. It's kind of a diagnostic tool. Now they did upload, they got the logic we plugged in into the PLC, and they modified a couple of parameters so they kind of messed up with our program and then they did upload a download. Download procedure is the opposite procedure of upload. It transfers the logic, the program to the PLC. So now the PLC basically has new software it needs to run. And obviously, boom. Now, at least this is what the attacker thought was happening because in reality, our PLC just turned the red system fault led and that's it because it did nothing. Now, we all know that the best motivation to do some kind of a research is revenge. So we were really furious on these script-kitted attackers that modified our logic and probably thought they're exploiting some kind of a nuclear plant or something, but we really wanted to get our revenge. So we came up with a plan. And the plan was to, again, use the PLC as a honeypot, weaponize it in some kind of ways that at the time we did not know how exactly, and use it as a bait. Now, we wanted to wait for an attacker to use showdown again because they're so sophisticated to scan our external IP address. And then, as we knew, their methodology is to do upload. So when they're doing upload procedure, we would somehow use our weaponized PLC to attack them and execute code on the attackers. So this was our plan. Now, in order for me to explain the concept, we need to go through some terminologies. So let's start with what is a PLC and what is a download and upload procedures. Now, a PLC is a programmable logic controllers. It's a small device computer used to control and automate the physical process. Basically, it means it controls field devices. It can be sensors, temperature sensors, for example, or actuators, such as lift or motors. Now, in order to the PLC to do something, we need to program it. And the way to program it is to use a software called Engineering Workstation. So we're developing our software in the Engineering Workstation software, and then we're transferring this to the PLC, and now the PLC has the program to control the field devices. Now, let's see a cool example. This is, for example, the GE Mark 6 platform. What you can see here is the IDE, the Engineering Workstation, and you can see here some kind of a specific PLC programming language. This is a graphical one with boxes. And we're using this to transfer the logic to the controller. In this case, this is the Mark 6 platform. And once the PLC or the controller has the software, the logic that we transferred to it, it can control a physical process. In this case, this platform is mainly used to control physical processes in the green energy fields, for example, to control wind turbines farms. Now, from a high level perspective, we first need to develop or to program the logic. And we usually use PLC programming languages, for example, ladder diagram or block diagram logic. These are usually graphical programming languages, so it's kind of a boxes or functions that we're writing our logic with. And basically what we're doing is kind of a flow to do some work. So we're asking the PLC or the controller to check value from one of the sensors and if the value is greater than x, then maybe start to defend to cool the room. Now, this graphical representation of our logic is in GE, is also represented as x and l behind the scenes. So you can see here the different pins for the functions and the function itself and some other parameters. Now, this entire representation of our logic needs to go through some kind of a compilation process. So basically we need to transfer what we want, what we have in our mind through the graphical representation to some kind of a bytecode representation so we could transfer it to the PLC. Now, in the GE example, and again, this is one example of many ICS vendors, in the GE example, they're using something they called P code. This is an intermediate bytecode that eventually will be transferred to the controller. And you can see here, for example, this specific byte represents the add function and obviously we can break it down and parse it, but this is just a general example. The next phase would be to transfer this logic to the PLC or the controller. For example, in the GE, they're using a proprietary protocol to transfer this logic. So they have SDI protocol that is being used to transfer the logic that we're writing, programming in the engineering workstation, compiling it to the P code intermediate bytecode and then using this protocol to transfer everything to the controller. And lastly, the PLC needs to execute it and what it does, it receives the bytecode, decodes each byte and then executes using native machine code. And this is how we control, this is how the controller is controlling the physical process. Now, the two most important aspects of it is upload and download, as I've already mentioned. The download is used to transfer logic to the controller. This is from the engineering workstation to the controller. While upload is usually used to do the opposite, to get the logic from the controller to the engineering workstation, so we could debug it and see in real time what's going on. So for example, we can do upload, get all the logic currently running on the controller, modify it and then use download to set back the new logic. So as I said, most of the time we're using bytecode that being transferred from the engineering workstation to the PLC. However, we discovered that in download and upload procedures, not only bytecode is being transferred to the controller, we have the bytecode itself, which is the actual logic, but we also have the source code that transferred to the PLC. We have symbol table with all the information about the variables. We have input and output configurations, device configurations, network configurations, variable definitions and more. And this is all being done so we could transfer the program to the PLC, but also so we could debug it. So we're kind of transferring a lot of data objects and metadata that is related to debug information and configuration and metadata. Now, we also have upload, which retrieves back all these data objects from the PLC to the engineering workstation. And we discovered that the PLC only cares about the bytecode and the configuration. Even though it receives the source code and the metadata, it does not parse it and it just sits being stored on the PLC. While in upload procedure, the engineering workstation has nothing to do with the bytecode because it does not have a decompiler in it, but it only cares about the source code and the debug data. So we were very curious, how can we attack advantage of this? How can we store some information or data objects on the PLC that will not affect the PLC, but when retrieved by the engineering workstation software, something will happen. So I guess you're all in the same mind with me, so we're going to the evil PLC attack. Now, in the evil PLC attack, our goal was to weaponize the PLC so we could attack the engineering workstation. And to do that, we decided to store malicious data objects on the controller and to weaponize it. So the PLC will be weaponized because it has some malicious data objects that does not affect the PLC because it doesn't parse the source code, for example, or other debug information. While the engineering workstation, when someone will do upload, for example, our skip kid is from earlier, will do upload, they will retrieve all the information stored on the PLC and hopefully we will be able to find a parsing vulnerability or some kind of a flow in the parsing of these data objects that will get us code execution on the engineering workstation. Now, we decided in our research to research seven industry-leading ICS vendors and to see if we can implement our concept on each platform. Now, when we're researching ICS vendors, the first thing we need to do is to obtain the hardware. And it's very difficult to obtain hardware on ICS. All you need to do is to go on eBay. So basically you can buy almost any PLC, turns out, yeah. We're not aware of it, but it turns out like you can buy any hardware you want on eBay. You just need money for this. And this is how we got our hands on all the equipment we needed. So we first had setups of seven different product lines, seven platforms connected in our lab. And we also configured the engineering workstation to communicate with these devices. The next step in our research was to understand the upload and download mechanisms. So what we did is we reversed engineered the engineering workstation, but also the PLC firmware. We also analyzed the communication between the software and the PLC. And we did all of this to understand what is stored on the PLC and also retrieved by engineering workstation and how can we take advantage of it and how can we know what is being parsed on the engineering workstation and eventually we wanted to find vulnerabilities in the parsing flow that will lead us to an exploit. So what we wanted to do is to store malicious data objects on the PLC, find a vulnerability in the parsing flow of the engineering workstation and then hook everything together. Now, this is exactly what we did and we were able to find seven zero days, a bit more than seven zero days, but seven chains of vulnerabilities in all the affected platforms. And to do that, we had to research all the different platforms including the engineering workstation. We had to reverse all the different parsing flows. We had to understand how they implemented the upload and download mechanisms in each platform and we also needed to implement our own client of these proprietary protocols. So we had to look at a lot of assembly code but eventually it worked out well for us because we were able to find all of these bugs and hook it up into chains. So I want to give you an example of one of the platforms that we researched to do some magic. So the example I'm gonna give today is about GE Mark 6. So this is the platform that is mainly used in the green energy fields, for example, to control wind turbines. And this platform runs the architecture of the controller is PowerPC Big Indian. It runs real time operating system RTOS of QNX which was very helpful for us because it has a micro kernel of UNIX. And the engineer workstation is called Toolbox SD. It's a dotnet application written in C-sharp. So again, it was quite easy to reverse a journey using reflection. And the protocol between the PLC and the engineer workstation is called SDI runs over TCP port 5311. I'm not sure if you can see but you have all the components on the screen. You have the engineer workstation, the Toolbox. Next to it, you have the controller and down below you have an example of one of the packets from Warshark. Now, the first thing that we wanted to do is we wanted to understand what is being stored on the controller. Again, we were looking for a data object that the controller stores but does not use or parse because we wanted the PLC to be left unaffected. We found that the binary code or the P code is stored as dot P code which was very convenient for us. And the source code is stored inside an archive file called device.zip and inside we had all the XMLs we've seen previously. Now, the PLC or the controller does not care at all about the source code. It just sits there so whenever the engineer workstation will request it, the controller will be able to transfer it to the engineer workstation. So now we knew what is being stored on the controller but we also needed to understand what are the parsing flows in the engineer workstation. So, we were looking for the upload procedure and this is the main function in the toolbox STIF program for the upload procedure. And in the upload procedure, we discovered that it reads a lot of files and one of the file it reads is the device.zip archive. Now, we found out that the engineer workstation fully trusts the controller and so when the file is retrieved, it is being extracted without any limitation or sanitization and so we were able to find our first vulnerability, zipslip. Now, zipslip gives us the ability to overwrite any file we want in the system and we needed to think how can we weaponize the controller by writing any file on the system. So, what we decided to do is to search for DLLs that are being loaded after the upload procedure is completed and our goal was to drop a DLL that will get loaded by the engineer workstation after the upload procedure completes. And we did find such a target, it turns out that blockware editor.dll is a good target because this DLL is loaded immediately after the upload procedure and so what we did is we took the original DLL, we injected our own CIL code into one of the functions that we knew is getting called by the API and we weaponized an archive, the device.zip archive and we wanted to transfer this new weaponized zip into the controller and to do that we had to implement the SDI protocol and the SDI protocol is a proprietary protocol so we had to do a lot of reverse engineering in order to break the protocol stack and understand exactly all the authentication processes and all the procedures of download and upload and implement it to our self and the main functions we needed to implement are x18, x19 and also x10. This is to let the controller know that we want to start down malicious download procedure in our case and also override the archive, weaponize the archive on the controller and we actually implemented everything so I have a cool demo to show you. Let's hope it works. Yeah, okay, the video works. So what you see here right now is us weaponizing the archive on the controller. So this is the attacker side and now from the engineer side they're doing, they have a new platform, they want to do upload to see what's going on on the controller so they will go on the toolbox as the platform, plug in the IP of the controller and do upload. So right now all the different files are being, yeah. And now we have a cool run somewhere on the system. Thank you very much. Yeah, so one platform is not enough and I already told you we've researched seven platforms and we implemented seven different chains with many bugs which are all disclosed and fixed and mitigated, yeah. And I want to show you some cool video we've prepared with all the different videos we shared with the vendors, so let's see. Yeah, so right now I've seen all the videos at the same point so right now what we're doing is we're doing the malicious downloads so we're weaponizing all the platforms and once all the platforms are weaponized we will wait for our fake run somewhere to jump on different engineering workstations. These are the original videos we shared with the vendors so that's why you see, so it started with a calc on some of them and then it transferred to MS Paint and finally to the fake run somewhere we thought would be cool to show. Eventually, yeah, eventually we did end up with a full working POCs with our fake run somewhere on all the platforms and it was a great research and it helped us to understand some new concepts in attacking ICS equipment and POCs and thank you very much.