y'all are in for a treat today. He's about to go give his talk on evil PLC attacks and I'll let
you take it away. Thank you. Thank you very much. So let's just make sure everything works.
Looks like it. Okay we're ready to go. Um 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 PLCs,
programmable logic controllers. So let's start. I'm Shorvan Brezinov. 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 Pwn2Own, Miami 22 and 20. I also own a dev conference
on black badge. Whooh. For winning the ICS CTF. And I'm mostly enjoying breaking PLCs. And I'm
not sure if you can see in the small picture this is our cool lab in Tel Aviv. Um special thanks
to my colleagues who worked on this research with me. Mashab, Uri, Noam, and Amir. Thank
you very much. Okay so the agenda for today is to give you a little bit background and
motivation for this research, why we started it. Uh we're going to talk about the
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 so we could propagate and attack engineers and technicians so
let's start with a 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 you 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 the what
used to be GE now it's Emerson RX
X3I. These are all 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 have been hacked. But our honey pots, the real honey pots, were hacked OT style. What
does it mean to hack OT style? It means a bunch of script kiddies used Shodan to scan the
Internet and then used the commercial engineering workstation. This is the software that the
vendors are distributing alongside with the hardware to program and monitor our
the PLCs. 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
shutdown or census. And what they did is they changed our logic using the engineering
workstation. 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 workstation 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 workstation what is currently running on the
PLC. It's kind of a diagnostic tool. Now they did upload. They got the
logic. We plugged it into the PLC. And they modified a couple of parameters. So they kind of
messed up with our program. And then they did upload, 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, the PLC is running on the PLC. And so
the 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 research is revenge. So we were really furious on
these cryptic 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, we wanted to get our revenge. So we came up with a plan. And the plan
was, we wanted to get our revenge. So we came up with a plan. And the plan was, we wanted to get our
revenge. So we came up with a plan. And the plan was, we wanted to get our revenge. So we came up
with a plan. And the plan was, we wanted to get our revenge. So we came up with a plan. And the
get our revenge. So we came up with a plan. And the plan was, we wanted to get our revenge. So we
came up with a plan. And the plan was, we wanted to get our revenge. So we came up with a plan.
And the plan was, we wanted to get our revenge. So we came up with a plan. And the plan was, we
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 a 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 for 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 VI,
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 VI 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 forms.
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 the fan to cool the room.
Now, this graphical representation of our logic is,
in GE, is also represented as XML behind the scenes.
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, we need, the PLC needs to execute it.
And what it does, it receives the bytecode, decodes it,
downloads each byte, and then executes using native machine code.
And 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's being transferred
from the engineering workstation to the PLC.
However, we discovered that in download and output procedures,
not only bytecode is transferred,
is being transferred to the PLC,
is being transferred to the controller.
We have the bytecode itself, which is the actual logic,
but we also have the source code 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,
it's 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 take 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 debugging.
.
.
.
While the engineering workstation,
when someone will do upload, for example,
our skip kiddies 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, it turns out.
Yeah, we're not aware of it, but it turns out, like, you can buy,
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.
So what we did was we identified and
processed the parsing flow that would lead us to an exploit.
So what we wanted to do is to store data,
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 where 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 we had,
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 VI.
So this is the platform that is mainly used
in the green energy field, 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 microkernel of UNIX.
And the engineering workstation is called Toolbox ST.
It's a .NET application written in C-sharp,
so again, it was quite easy to reverse engineer
using reflection.
And the protocol between the PLC
and the engineering workstation is called SDI,
runs over a TCP port 531.
And I'm not sure if you can see,
but you have all the components on the screen.
You have the engineering workstation, the toolbox.
Next to it, you have the controller.
And down below, you have an example
of one of the packets from Wireshark.
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 .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 engineering workstation
will request it, the controller will be able to transfer it
to the engineering 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 engineering workstation.
So we were looking for the upload procedure,
and this is the main function in the Toolbox ST program
for the upload procedure.
And in the upload procedure, we discovered
that it reads a lot of files.
And one of the files it reads is the device.zip archive.
Now, we found out that the device.zip archive is a file
that the engineering 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, zipslip is a file that we want
to use 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 engineering workstation
after the upload procedure completes.
And we did find such a target.
It turns out that blockwareeditor.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 it.
And exactly all the authentication processes
and all the procedures of download and upload
and implement it ourselves.
And the main functions we needed to implement
are x18, x19, and also xd.
This is to let the controller know
that we want to start a malicious download procedure
in our case, and also override the archive,
weaponized archive on the controller.
And we actually implemented everything, so I have a cool demo
to show you.
Let's hope it works.
Yeah, OK, 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 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.
OK.
All of the different files have been, yeah.
And now we have a cool ransomware 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, yeah, 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 synced 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're going to do,
we will wait for, yeah, for our fake ransomware
to jump on all the, 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 ransomware we thought
would be cool to show.
Eventually, yeah, eventually we did end up
with full working POCs with our fake ransomware on all
the platforms.
And it was a great research, and it helped us to understand
some new concepts in attacking ICS equipment and PLCs.
And thank you very much.