 Hello and welcome to our talk top-down and bottom-up exploiting vulnerabilities in the ulti cloud era Before we begin, let's talk a little bit about who we are so My name is Sharon Brazil of I'm a vulnerability team risk vulnerability research team lead at Clarity and with me is Uricats our senior security researcher at Clarity and we're part of the team that Researching and trying to find vulnerabilities in all the equipment so you can see in our background and In the picture in front of you our cool lab. This is our playground that where we're trying to find and exploit vulnerabilities We're working with different vendors to find vulnerabilities disclose the vulnerabilities to the vendors and Basically what we are working with them to fix any security issues that we're finding and Eventually, we're Publishing our research on the vulnerabilities that we're finding so you can see the table in front of you of some of the vulnerability that we found in Many of the ICS vendors. We're also participating in different competitions We've participated in poem to own in 2020. We've participated in Defcon ICS CTF and where we won the first place and we're doing and conducting lots of research and competitions in those areas so With that we would like to discuss today a little bit about SCADA infrastructure and the cloud so we would like to Describe what it means of ICS security in the cloud what it means to have infrastructure in the cloud and how can devices ICS devices and all the equipment can communicate with Cloud infrastructure outside the parameter and outside the OT network. So let's start with What is a typical SCADA infrastructure so we have the Purdue model as you're all aware of We have in a couple of layers that in each layer we have different devices with different capabilities and roles in the lowest level in level zero we have a field devices field devices or actuators and sensors They are communicating. They're sensing and Doing actual and physical work in our world above that we have PLC's so we have the brains PLC's and RTU's and above that we have HMI's and Engineering stations that are controlling and interacting with the PLC's so for example if I would like to download code to the PLC I would use engineering station to program The logic and transfer it to the PLC In which the PLC will The adjust the logic will execute the logic and control the field devices the sensors and the actuators So if we're taking this image or the Purdue model to be very concise we can see here just engineering station and the HMI communicating and interacting with PLC's and the PLC's are connected to valves in this example and The PLC's are actually doing something physical Sorry the valves are doing something physical in our world where the PLC's are controlling those valves and Humans the engineers still parators are controlling the PLC's through the engineering station and HMI the engineering station is meant for programming and configuration Mostly while the HMI is mostly for data acquisition and for the engineers to understand What's going on within the process? so if we're We're for taking this further today. There is Huge trend to move everything to the cloud It started with IT infrastructure servers are no longer physical boxes They're kind of a server somewhere in the cloud and it's starting to Get into the ICS and OT networks too and we're seeing more and more devices starting to be controlled and Managed by cloud-based infrastructure and we're also seeing this through cloud-based Cloud-based SCADA infrastructure as well. So Why do people want to move to the cloud? There are a couple of reasons first of all telemetry so All the devices are transmitting telemetry always to the cloud So it's very easy to control and understand what's going on in all of the devices There are nice dashboards and trends and graphs So it's easier to understand what's going on in terms of telemetry and logs The management of logic can be done through the cloud So usually there is a console management that you can go into and Manage all of the devices that are being controlled by the the cloud infrastructure Which means we can download logic through the cloud to all the devices at once. So it's very easy setup We can have lots of diagnostics and troubleshooting because everything is connected to the cloud You don't need to be inside the network You can be somewhere in the internet just go online to the website the console management that is exposed to the internet and Diagnose and do some troubleshooting get all the logs and manage the The fingers manage the logic of the devices and control the devices Remotely without the need to be physically inside the network and obvious obviously It's a centralized view of processes and redundancy. So when we're talking about cloud-based infrastructure, we're we're usually Talking about lots of instances in different regions So we have lots of redundancy and we can control and manage all of the devices that are directly connected to the cloud so if we're taking this a bit further and We're Re-evaluating the new Purdue model. So basically it's all broken. We don't have these layers anymore because all the PLC's And when we're talking about ICS infrastructure that is connected to the cloud all the PLC's all the HMI's all The engineering stations are basically controlled and managed through the cloud So there is no longer a need for the Purdue module because everything is connected and managed Through the cloud all the PLC's are connected to the cloud from one side and the cloud or the management Console which is basically a website in the cloud of which engineers operators administrators Can log in to the internet in to the web page in the internet somewhere in the cloud we're seeing and Control and manage these devices. So if we're re-evaluating the The little screenshot that we've seen before so the engineering the HMI and the PLC now We don't need to be in the same network because the PLC's are connected directly Outside to the parameter connected directly to the cloud, which is a server somewhere somewhere in one of the cloud providers such as AWS, Azure or Google computer GCP so we're having the functionality of the HMI and the engineering Provided through the console management in the cloud where engineers can just go online to one of the websites and Manage the devices that are controlled by the Management console and the scatter infrastructure through the cloud So everything is much easier for engineers and asset owners because now they can control all of the equipment Through the cloud which means through the internet and they don't have to be physically present inside of the network So what kind of roles do we have with this kind of new infrastructures? So we have the same old roles such as programmers that are writing the logic We have management which are kind of the People are managing the OT managers that are managing the operations and managing the process So they're doing kind of view reports with kind of HMI functionality or device commissioning when they're buying the devices And we're also having the administration level which is responsible for creating the accounts and they're responsible for security So all of these different roles are communicating To the cloud-based management console. So they're communicating with the management console somewhere in the cloud basically and usually it's a website where they can go online log in and then Depending the functionality they can program they can upload Program or logic to be transferred to the end device to the edge device or they can view reports It's kind of a HMI screen. You would say or Do some kind of administration processes such as creating new accounts for engineers or OT managers or Fix permissions and policy for other users. So all of these world roles or different personas in in This infrastructure are communicating with one Entity which is the cloud-based management console and everything from there is flowing To the PLCs or to the end devices which can be other devices than PLCs and control and Manage these end devices through the management console So this is the new era where everything is connected directly to the internet and there is no no longer need for VPN accesses or other kind of Being physically present inside the OT network. This is the modern era now, let's we want to give you an example because All we said up until now is kind of abstract their PLCs and devices connected to a cloud-based management console and we have Engineers communicating with this console to control the end devices, but let's give a Real example and we have Codesys. So Codesys is European company It's a it's a great Fendall. We're working closely with and they're developing Their development system which enables programming and configurations of PLCs So you can you can use their platform to create logic and download this logic to the PLCs the PLCs are usually running the Codesys runtime, which analyzes and dissect the logic that you the engineers are writing using the Codesys development system and The PLC using the Codesys runtime can execute the logic to control field devices Such as actuators and sensors. There is a variety of PLCs and vendors that are using Codesys as part of their runtime Engine so we have WAGO and we have ABB AC 500 with PLCnext and then many more and Codesys can even run on Raspberry Pi and And other platforms as well. So here is an example of Codesys IDE As you can see It's kind of a basic idea where you have the target the PLC target and you have The IDE interface where you can write the logic. It can be a ladder diagram where it can be structure text or other ICS related programming languages and you can compile the logic and transfer it to the Codesys runtime Which it sits on one of the supported PLCs and platforms. So this is a Codesys IDE and Codesys development system. Now Codesys took this one step further and Created their own automation server. So instead of managing PLCs back-to-back kind of with The necessity to be in the same network. They've created the Codesys automation server which allows Codesys supported devices to be connected to a centralized cloud-based management console where asset owners can manage PLCs remotely So basically they can just like we discussed previously they can manage and Control all of the supported PLCs remotely through the cloud for every instance every every device that is linked and associated with the cloud and Codesys are providing lots of features above this cloud platform So basically they're offering HMI capabilities with their with their WebVisual platform. So basically you can create screens that that you can see through the A kind of a nice GUI of what's going on in the process because the PLC is Sending telemetry and data all the time to the cloud. So you can visualize all the process Using their webVisual features and you can also use their kind of engineering working station capabilities to create logic using using their IDE transfer it to the cloud-based platform Which is the automation server and download the logic and configuration to all the connected PLCs again everything through the internet so basically when you're Setting up your account in Codesys automation server you will receive your own AWS based instance and you can see here an example of such an instance and this is a Personal instance for each account that you can just go online to this instance and control all the associated Linked devices. So let's see an example real quick Here is an example to devices that are being controlled through this platform So basically what you're seeing here is a website somewhere in the internet using one of the instances that Codesys created for the account and You have all your linked devices To control so you can go in into one of the devices and do a download logic You can change configuration You can change settings on these devices and everything will be Transferred and downloaded to the PLC because the PLC is directly connected to the cloud platform Now Codesys took this even one step further and created the Codesys store So basically it's like the Apple store or the Google Play Store where you can download applications But just for your code and your process So basically you can download examples of already created applications or you can download libraries or you can download Clients that will be run on the PLC and you can use the store to accelerate the development cycle and Use code that other people wrote without inventing the wheel. So if someone else wrote the code to Process some kind of a mathematical Algorithm so you can just download the the library that he created and maybe pay for this if they're selling this With by money or not or you can download for free if The developers are offering this for free, but the basic idea is the same you can just As a developer you can offer your own code or libraries or programs that others can download and use in their projects So this is an example of AWS IoT core client that is being offered for free as you can see here And other developers and asset owners can download and use this library for free to integrate their PLC with AWS IoT platform and The final feature that we want to discuss Regarding Codesys is the web vision. So it's visualization Kind of a HMI in the internet browser via HTML 5 so we can create all these kind of different screens To interact with so basically the PLC's that are linked to the cloud are sending telemetry and data all the time about trends about tags about any anything that was configured in the logic and You can create screens that will take off the aggregated data to present In a very nicely presented view and gooey just like a normal HMI Just in the cloud just in a screen That is based on HTML 5 and it's very easy to control and create nice screens that anyone can access with the proper ACLs so We have engineering working station and we have HMI and we even have the Codesys Store to create download applications and we have every all these services in one platform That is connected through the cloud through the internet and all the connected PLC's can be managed to control and Present information everything directly through the internet. So this is a great example To what we discussed earlier now. We wouldn't like to discuss a wago. So wago is a German company European and company They have two main product PLC products, which are the 750 and 750 exterior and the PFC series PFC 100 and PFC 200 We mainly focused on PFC 100 and 200 and this is an example for a PLC that is Linux based and It is running the Codesys runtime so it has a great integration with Codesys and All the great features that I mentioned earlier can be used with the wago so basically wago runs the Codesys runtime and The Codesys runtime can communicate with other Codesys related platforms and systems So this means that we can control our wago PFC 100 200 using Codesys automation server and basically manage all of our wago PLC's through the cloud So the wago PFC 100 and 200 is a is a basic PLC It runs it has lots of functionality that most of PLC's Contained these days support of all standard field bus protocols and Ethernet standards such as profit bus mod bus profit Ethernet etc. And it has lots of interfaces such as RS485 and RS232 and As I've mentioned it is running The Codesys runtime, which means it has great integration with all the Codesys platforms And even the programming can be done through Codesys and we will show you a couple of examples very soon So let's take a look at how the attack surface is changed after moving through the cloud And to do that we first need to understand what attackers are trying to achieve and it's pretty easy in the ICS world Attackers are either trying to gain money or to cause damage and Attackers reaching an OT network have a few options They can start by shutting down equipment randomly stopping PLC's and This is sometimes effective and really noisy More complex attackers will try to modify parameters And that requires a bit more knowledge about the operation itself and knowing what to change Another thing we can we see is Attackers wiping data and gripping data and this is mostly for money. We see that in the latest transfer attacks So Our traditional ICS attack looks like is the first attackers need to Bypass many protections and firewalls to even reach the OT network and Even if they reach a computer inside the network, they have some challenges most of the equipment is Backed up or has redundant equipment to take its place. So if an attacker stops one PLC the redundant redundant one will start working and There are also many safety checks along the way. So attackers really need to have a good Coverage of over the OT network in a in order to really cause damage in cloud attacks The thing that separates attackers from the OT network is usually just username and password and when attackers Gain access to a cloud. They have a full view of the operation and can instantly modify parameters and Change values in PLCs In our research we developed two main methodologies for cloud attacks The top down and the bottom up the top down starts with attacking an engineering station Then going up to the cloud and attacking all of the managed PLC The bottom up attack starts with the PLC Then we climb away up the cloud to take control over the entire operation So let's start with the bottom up attack we use the Wago device to demonstrate this attack and Wago devices have a configuration port open on port 6626 and this is used for the initial configuration like setting their hostname or subnet for the device This port remains open after the initial configuration, which gives us a big attack surface So we found two vulnerabilities in the IO checkt process And a shared memory overflow and the stock buffer flow Let's start with the shared memory overflow The IO checkt has a white register command which writes to a certain memory location and this is limited by the count parameter We found out that that the count parameter is checked for every table that you can write for except for table 99 Which is also Stored in the shared memory region So we were actually able to use the white register command to write more than the size of table 99 and Overflow it into another memory region And the memory region is in the shared memory. So by itself, this is not that useful The second vulnerability we found is in the Response for the read variable command The read variable command assumes that the maximum size is 1400 bytes and this is the maximum count This is the maximum count size But if we are able to write more than 1400 bytes, we are able to Read more than that. So the read register command for table 99 can return more than 1400 bytes and copy that to the stack buffer of the response and In that way, we can write our payload using the write register command and While reading it with the read register command overflow the buffer with our payload So this is the output of a script that runs the full remote code execution So after we got our remote code execution, we started looking for ways to get up to the cloud and We discovered the code sees a web-visual option This option. Let's you write the JavaScript and HTML pages on the PLC and present them remotely This option is also open from the cloud, which means that any Operator of view in it will have a cloud cookie So if you have control over the PLC itself and We can change the JavaScript for example We can change it to get the cookie from the person unit and Create a user for the cloud where we control the username and the password So this gives us a new user in our control in the cloud So let's chain it all together. We start with a read and write register buffer overflow That gains us remote code execution on the rubble PLC then we change the JavaScript to Create a new user in the cloud and we use that cloud to take over the entire operation so starting from PLC and Going up to the cloud and using that to Manage and control the entire operation the second method we developed is the top-down attack the top-down approach starts with targeting and engineering station and We decided to look at the code sys packages Packages are just normal zip files, which contains dependencies and sometimes even dealers We discovered that those packages are not signed and we can change them to contain our malicious code So we actually made a package That when an engineer installs that would get his code credentials from the engineering station and send it back to us So once we have access to the cloud we can change run modes of the PLC is Stop them or even a change process values But the holy grail of attacks is to actually run native code on the PLC is This is not yet published so we can't speak about details here but we actually managed to Run native code on the waggle PLCs from the cloud So once we have the cloud credentials We were able to execute code on all of the PLCs in the operation So a quick recap on the top-down attack We create a malicious package uploaded to the code sys store operators install this package and The cloud credentials of the operators are sent back to us then we can do whatever we want with the With the operation and we can stop PLCs. We can run code. We can do anything we want with the operation So starting from an engineer Moving to the cloud and then to all of the devices in the operation That's it for today. Thank you everyone who attended our talk in Defcon 29 ICS Village We hope you enjoyed our talk about attacking cloud-based infrastructure in ICS and If you have any questions now, it's the time. Thank you very much