So, hi everybody. Good afternoon and welcome to this talk in the ICS village here at DEF CON,
or there in DEF CON. This talk is the journey of ICS project files from visibility to forensics
and exploitation. And I will explain what this means and what we'll talk about in a minute. But
first, who I am. My name is Nadav. I'm the head of the research team at Clarity. And just a bit
of background, Clarity is an ICS cybersecurity company. What we do is protect ICS networks.
This protection is usually based on a deep understanding of the protocols and the assets
that exist in such a network. And the job of the research team at Clarity is to do just that,
is to investigate different ICS devices, different ICS protocols, to understand
what a proper behavior is, what something that's a bit different that might be dangerous would look
like. And based on this understanding, to improve the protection of the networks that we protect.
I think that's the main agenda of the Clarity research team. But not only do we understand
how the protocols work, we also usually use this understanding of OT networks and OT environments
and leverage it to vulnerability research. So the team basically also plays with the PLCs,
plays with the OT software to try and find vulnerabilities. And as you can see here
in the picture in the slide, that's our lab. That's what we call our playground. And basically,
what we do is we come in the morning and we start playing with PLCs. Or basically, now in COVID-19
times, we stay at home in the morning and start playing with PLCs. We've actually had to install
internet-based switches so that we can power cycle some of the PLCs from away if we did anything that
caused them to fall for some reason. And obviously, when we find these vulnerabilities,
we will report to vendors. We will have the vendors issue patches and advisories to,
obviously, to our customers and to the public at all. So that's basically my job. My job is
to play with PLCs and try to find interesting points security-wise in these PLCs. And here,
let's talk about what we're going to say today. So basically, the agenda is ICS project files,
the good of them, what are these project files, what do I mean when I say an ICS project file,
and what information it may contain and how it may be used for the good. The bad side is
once we've done that and we've understood how these project files work, how they look,
we will also try to understand why they may be vulnerable. They may pose some risk to the
engineer's computer. And lastly, the ugly would be, I would try to convince you that not only
these vulnerabilities exist, but they're not only theoretical vulnerabilities, they may be used
by an attacker to infect an engineer. So basically, the flow of this presentation would be
exactly the flow that my team and I did when we came to investigate project files. We started off
from understanding how these project files work and what information can be found in them,
so that we can better improve our capability to assist our customers in listing the assets in
the network and identifying any potential soft spots in the network. So we started by that. And
then when we looked into these project files, as we will do in a few minutes, we started understanding
that they may be a bit risky in how they work. And so we start looking into these vulnerabilities,
and then we'll go through these vulnerabilities that we found. So let's get to it. And I think
we best start with what is an ICS project file. Because when I say ICS project file, it doesn't
necessarily mean anything. So I think it's best to define this file. And let's start with what
is an ICS engineering software. So basically, here are a few just a few screenshots of very
common engineering software that we might encounter. And basically, when I say ICS project file,
what I mean is how this engineering software saves its information. So for example, if you work on
configuring a PLC using the B&R Automation Studio we see here, then the engineer would want at some
point to save all the work they've done, so that later on they can use it or they can reopen it,
they can edit it or anything like that. An ICS project file would be a file, a directory,
anything, an entity in which all this information is saved. So when I say ICS project file, it doesn't
necessarily mean just one specific file. It means the logical entity in which the ICS software saves
all its information. And when that is the definition, you can start thinking and translating
it into the information that we expect to find in these project files. Because I want to convince
you that these project files are interesting. Don't forget, we came into this challenge trying to
improve our capability to understand networks by looking at these project files. So let's think
what information we expect to find in these project files. And obviously, we'll start from the
topmost layer. And I think it makes sense that a project file that describes a plant or a
manufacturing site or anything like that would have to contain the network layout. So from the
topmost layer, we will see the network layout. As you can see here, some screenshots from the
Step 7 engineering station by Siemens or from Rockwell's engineering software. You can see that
it holds a list of assets in the network. So for example, here we have a profit bus
with a few S7-400 stations. And we can use this file to identify that we have
four stations along this bus and understand what they are and where they are. Next, let's dive
into these stations because this project file has to contain information about the specific assets
within the network. And so looking at the specific asset, you can see just a few more
screenshots here describing how we may identify all the different slots on the device.
So as you can see here, again, a snapshot from Siemens's software showing the exact slots and
the model and the order number and the firmware for every slot, which is very interesting information.
We can see that it also has, for example, here from BNR, you can also see the serial information,
the serial number, or the network addresses. So the information about the hardware of
every device in the network is very interesting and exists in these project files.
But we can also dive even deeper because these engineering software obviously are used to
engineer. And so programming the logic on these devices happens through these softwares and we
would expect it to be saved within these project files. And indeed, diving into one specific device,
looking into the guts of what is saved in this project file would be the actual logic.
So again, a few screenshots here, but you can see that these project files will contain the block
diagram, the ladder diagram, whatever type of logic we configured, we expect these project
files to contain it. So that's going from the topmost layer of the network
to the internals of a specific PLC, the actual logic that every PLC is running.
And so I think hopefully that shows you that these project files are useful. They are able to provide
us with a full inventory of assets, their details, their models, their firmwares, whatever, and of course
also their logic, which is great for us and great for the engineer to use as backup,
which is nice. They're also very easy to collect. The advantage with looking into project files,
and here again, think of me as a person wanting to improve the visibility into the network,
one alternative for me could be, for example, to just capture traffic from the network and try to
map the network from this traffic. But capturing traffic requires a lot of work. It requires
configuring expand ports, it requires waiting for interesting traffic to come, whereas looking into
project files, all it means is that I have to access the file on the engineer's computer or on
the backup server, because an engineer would probably use some kind of backup server that will
hold all these project files in one place, so I don't have to look far. And I have these files
at the palm of my hands without having to work too hard. And once I do have these files, all I
have to do is just write some kind of script that knows how the file is built,
and we'll get to it in a few minutes. And once I've done that, I can, within seconds, determine exactly
all those details that I could, that I showed you just a second ago, starting from the network
and going down to the actual logic. So that's very great, and that allows us to collect a lot of
information within a second. But the next question should be, why do I care about this information? So
why did we, why do we mind about the network or about the model information?
And my claim is that the first step in securing an OT network would be this type of visibility,
not only in securing, also in promising the continuous operation of such a network. But
obviously, my perspective and Defcon's perspective is the security side. So let's start with network.
Obviously, mapping the network is critical to understanding that any new devices connected
to the network could be a malicious actor who connected to the network. And obviously,
on the other side, identifying that a device is missing from the network, could be something
happened to a device. And so we need to have this full picture before we start diving into the
network to identify any changes that might have happened. Next, it also helps us to identify the
roles of assets within the network, because if I have this project file, I can identify that every
PLC has a specific responsibility. And so this PLC is part, is in charge of this part of the
process line. And this PLC is in charge of that part. And so when anything we don't expect happens,
I will be able to quickly identify what is the root cause of that. And also, it will help me
manage these PLCs and assign people in charge for them, for example, and more. Next, we will have
the detailed inventory. Because as you could see before, we also have the model, we also have the
firmware version, and that's great for an engineer or for a security person to assess their security
posture. Because when you know how many devices you have of each model, and what firmware they're
using, you're able to identify very quickly how vulnerable you are to a new vulnerability that
might have been published, how deep is your backlog in terms of firmware upgrades you need
to perform on your devices, because you don't want to be too old or too vulnerable. So having this
detailed inventory allows you to know where you're standing and keep yourself up to date with
any new releases by vendors, for example. And lastly, when something does happen, it might be
a security event, it might be an operational event. But when something does happen,
if you do have a snapshot of where the plant was or where the site was yesterday, it's a lot easier
to identify what has changed and what might be the root cause of the issue today. And also it's a
lot easier to start everything up again tomorrow, because you know exactly where you are. You can
use the configuration files, the ICS project files, to reconstruct everything very quickly.
So you can also identify the cause of the issue and start again, which is great in terms of incident
response in the OT industry where downtime is critical. So hopefully, I convinced you that
that this information is critical, that ICS project files hold interesting information and
that this information is important. One side note that is not the main issue that we speak about
in this presentation, it has been spoken of in previous presentations, but one side note is
seeing how these project files contain such valuable information also means that they may
be used by malicious actors themselves. Because a malicious actor trying to plan an attack on
an OT facility may use this information in the project files to plan their attack better, to
identify vulnerable devices, to map tags on specific devices that affecting them would affect the
the operation of the plant. And so these project files are very interesting from a security
perspective, both from an operational perspective, both to the OT engineer, but also to the
hacker doing the recon at this stage. So that's just a side note that these project files need
to be saved. I know that a lot of people like saving their ICS project files on a Dropbox
folders, etc. That's something to think of and making sure that these shared directories are
secure. So ICS project files at this point, and hopefully if I convinced you that the
thought process that we had convinced you, ICS project files are great. It's a super easy way
to get tons of information that we want, which is very nice from Clarity's perspective or
from my perspective, because the things I had to do to get all the model information of
all the devices in the network before were a lot more complex. And now all I have to do is
understand how a project file is built, and have the engineer provide me with the project file,
and I'm able to produce all the information. So that sounds super easy and super great.
But is it really? So I think this question builds up to what an ICS project file really looks like.
We only discussed what ICS project files are in theory. But let's talk about what an ICS
project file really looks like. What does it mean when I say ICS project file?
Sorry, so the most basic use case would be just a text file. You may go to the
software, you may click export on the software, and what you get is just an Excel file that
my grandma can open with her office that we just recently installed for her, and understand
everything in the network. So you can see that the IP addresses of the devices, the models of
the devices, the versions, which is very nice, very easy, very useful, and that's great stuff. It's not
very good for me as a researcher because then my boss will fire me if all files look like that,
but it's great for my grandma and for the common engineer trying to understand the network format.
And obviously, we have many formats, different formats of ICS textual project file. So another
example for a project file by one of Rockwell's softwares, and as you can see here, an XML,
which is also nice and very script friendly. If you want to write a script that will pass this
information, you can see very easily that you can see the name of the bus, you can see the type of
the network, you can see the host name of the devices. So for ICS project files being textual,
it's really great, and we have everything we need for that. But that's not always the case. Sometimes,
and for example, here, this is an ACB file. It's a file generated by the AliceLogix 5000,
the Rockwell software. You can see that while it starts as a textual file, and you might think that
your day is a good day, within a few lines, this becomes something that is clearly not English.
And indeed, this file is most of the information within it, and all of the interesting information
is saved in some kind of binary format. And so in this case, my grandma would probably call me and
ask for help. And this help will not be easy. You have to try and understand what this project file
looks like. You have maybe to reverse engineer the program, maybe to black box and understand,
to do some black box research and understand how this project file is built. And indeed,
that's what we have to do when we encounter such files. And you see that the Rockwell ACB file
is not the only case. This is an example for a Siemens device, a file outputted by the Dixie5
software, and another example by another Rockwell software, an older version of the AliceLogix.
So binary formats are very common as well. And in terms of research and understanding how they
are built, you have to work a lot harder for that. Still, not only do we have binary formats
or textual formats, we also have the cases where a project file is not really a file.
It might be a directory. This is, for example, the project file that is generated by the Siemens
Step7 software. And as you can see, it's just a directory containing a lot of subdirectories,
containing a lot of other subdirectories, containing a lot of binary files. And so the
project file here, the challenge of understanding where the information is, is not only understanding
what the binary format is, it's also understanding where the file is. And in this case, we just see
a few tens of project files. But as you can see here in this one of Mitsubishi's
softwares, you can see that we got a directory that's about 7,000 files. So you have a lot of
sifting through the files to do before you can start working for reals. And obviously,
sometimes these archives may not be just a zip archive or just a plain directory,
it may be a cub file. And I don't know how many of you are familiar with cub archives,
they're a very old format. And what is today has been replaced by zip. And just finding a
Python library to un-cub a cub archive is a challenge of itself, even though this format is
publicly available and everything. Just finding a script to un-cub the file was a challenge of
itself. But obviously, when it comes to directories, most of the files we need are zipped. And
obviously, a zip is just an archive that contains a directory. And what the software does is take
the whole directory containing all the information of the project and zip it into a single file.
And as we'll see in a minute, this file may be saved with a different file extension. So it
won't be .zip, it may be .something else. But if you just open it and check, you will see that
actually, in fact, that's a zip file containing a lot of other types of files. And we'll go into
that in just a second when we show an example. So just to recap, project files provide great
information, and they come in many, many, many shapes and sizes. And so we have to work sometimes
very hard to collect this information. So let's just see just one example, another screenshot of
the file. This file was generated by Crimson, software by RedLion, to program HMIs. And as
you can see, this file, while it's binary and not very readable for the common user, but you can
see just by looking at it that it does hold some interesting information. For example, if you look
here, you can see the model G306. And obviously, when we know that this file was used to configure
G306, then we can identify that this field shows the model. We still have to work into understanding
what... how do I get to this model? What means... how do I extract the model from this file?
But we see that it has a model. We can also see that there are some numbers here, not sure what
they mean. We have the string major, which might be a part of the major firmware version or
anything like that. And so the research team would have to do a lot of digging and some reverse
engineering into understanding what this Crimson file looks like. And the objective is
to turn this file into something that's human readable. So for example, here, as you can see,
what we were able to extract from this file is indeed the module and also the IP address. And
obviously, I can't see, at least with a glance, I can't see the IP address here, but it took some
work and some reverse engineering of the software to understand where this IP address is located
within the file. And we could also identify that this is indeed an HMI and identify the exact
version of the Redline Crimson software that was used to generate this file. In this case,
these files are compressed. So it's one compression method that is pretty specific
that was used to save all this information. Once they were uncompressed, we could start and
identify exactly the interesting fields within this file. So that's one example. Let's think of
another example for a project file. And let's have a look at the way the Siemens Step 7
saves its files. And as I mentioned before, basically, it's a directory. And so when you
export from the Siemens Step 7, you get a directory, which usually you will zip. And what
we get from our customers would be just a zipped file. And this zip extracts into this directory
containing many files, as you could see before. And looking into these files, what we identified
when we tried to find the interesting information is that one of the subdirectories within the SDB
subdirectory is the interesting subdirectory. But that contained a lot of files with the names
very informative names, 000a1.pg. So obviously, no file here is called,
I am the interesting file or model and firmware file or anything like that, but rather
these internal names. And so looking into these files, we identified that one of these files
contained the interesting information. And just by opening it, you can see, again, some interesting
strings hidden within this binary file. So you can see the order number again, you can see the model
here. And so now we've discovered what the file was, what interesting file, what is the interesting
file within this directory, we would still have to do a lot of reverse engineering to understand
how to extract this information from that. And that basically is the job that we do. We commit
to being able to understand the project file to extract all this information that we deem
interesting in this project file. And when we get a new project file, a new format, a new
requirement from a customer, what we will do is we will try to understand how this software works,
same as we will do for a protocol, same as we will do for any type of such request. So just let's do
a quick overview of what we see in these project files that we look into. And I think the most
common thing that is found in all or in a great percentage of project files in the world, no matter
the vendor, no matter the software, is a zip archive. Because usually these projects will
contain a lot of different files. For example, one file will contain the hardware configuration,
one file will contain the logic, one file will contain the list of assets, etc. And the project
file is simply a zip directory containing all these files. Looking into this project file,
and once we've unzipped this project file, we see a lot of files. And what we'll usually see,
and what is very common in these files, is first OLE files. OLE is a format used by older
Office documents, so it's a format by Microsoft. And it's a very convenient format for developers
to hold a lot of binary information in different streams. So it's very convenient, and we see it
in use a lot in ICS software. Next, we will see a lot of database files. And this makes sense
when you come to think of it, because these project files need to contain a lot of information
per every device. For example, you will need to contain the firmware, the model, the IP address,
etc., etc. And so it makes sense to save it in a database format. And so we see SQL databases,
MSSQL databases, a lot of database formats. One of these formats, just as a side note,
is the Access database, another format by Microsoft that was used by Access. And that's,
again, a very old format. And actually, so again, finding a Python library to access
such a database, we couldn't do it. We simply couldn't find a Python-native library
that could access the Access database. And so just a few weeks ago, we published our
open-source Python library to interpret Access databases, which is nice. Now you can do it just
by inputting in Python. Next, we will also see a lot of proprietary binary format. As I mentioned
before, no one forces the vendor to work with a specific database or anything like that. So the
vendor might decide that they want to save the information in their own proprietary format.
And they will design this format. They will write the code to access this format and to
parse this format, the information in there, and to obviously to save the information into this
file. And so we see a lot of proprietary binary formats. Lastly, as I mentioned before,
if you're really lucky from an engineer's perspective, if you're really lucky,
you will get a text file you can open and just review the text file and understand everything.
Obviously, from the researcher's perspective, it's less fun, because all you have to do is
open the text file. But in my perspective, still, this is a very convenient and a very good way
to save the information. So all that means that if we take a look back at what we discussed
so far about what project files do, what information they contain, how they are built,
then we can think of a few traits that are occurring. First is we see a lot of binary
formats that are developed internally. And as I mentioned just a second ago,
this is because the vendors will develop their own code and they will do that by themselves.
Next, we will see that if the format is proprietary or if it's public or if it's a
database or anything like that, still, a complex parsing is required in order to extract the
information from this file or to save the information to this file. Because we're talking
about a very big amount of information in various types. You sometimes want to save the IP address,
you sometimes want to save the compiled logic. So various types. And obviously,
it will require some complex parsing work. Lastly, it will hold some proprietary information.
Every vendor will save their own information. Every vendor will design the file as they wish to
save the information that they were looking for. So we will see a lot of proprietary information
in proprietary formats that will be complex. And thinking of all these three traits,
it sounds quite familiar, or at least to a researcher working in the ICS domain,
sounds quite familiar. It sounds quite familiar because these traits are very common in ICS
protocols as well. And so when we had reviewed enough ICS project files to extract the information
from them, and at some point we had a nice collection of ICS project files formats that
we support and understand, we started to think ICS protocols. And the next thought, as a security
researcher, when you think of ICS protocols, the next thought is oil. And the reason for that is
that vulnerabilities in ICS protocols exist, and exist a lot. And they are published weekly,
and these devices are very vulnerable. And the reason for that is that this code was usually
developed with no security in mind. And so when you're thinking of something that is comparable
to ICS protocols, your next thought would be, let's check how secure this may be. And indeed,
just a quick Google of ICS project file vulnerabilities showed us that not very.
The answer is not very. And so just a quick Google, and you can see a lot of vulnerabilities
that have been published in recent years. And just a quick lookup in the ICS self-website,
for example, for Advisor is published recently. You can see here one type of vulnerability that's
an SQL injection. Another is a use-after-free. Another is a stack buffer overflow. And so
vulnerabilities are constantly published on these devices. And all these vulnerabilities, as you can
see, are relevant to the ICS project files. And so these formats, these files, are vulnerable.
Not only they are vulnerable, they're also growing in terms of awareness to the vulnerabilities.
So just a quick example for that, we can have a look at the vulnerability that was published in
2016, just four years ago. And this vulnerability, and I put here the CV, is crashing the engineering
software with a malicious project. This means that if the engineer would double-click on a
malicious project, the engineering software would crash. And that vulnerability got, at the time,
a CVSS score of 4.2, which is a low CVSS score. And not only that, the Advisor contains this,
some kind of disclaimer sentence saying these vulnerabilities are not exploitable remotely
and cannot be exploited without user interaction. So that's some kind of disclaimer saying,
yes, this is a vulnerability, but no, it's not very, very interesting, or at least not
at this time. And the reason I'm saying at this time is because we can look at the same
vulnerability or similar vulnerability published in 2019. Again, a vulnerability that means that
when you open a project file, when you double-click a project file, the engineering station,
the engineering software would crash. And so the meaning of the vulnerability is the same.
But this time, and we're three years ahead, it got a CVSS score of 7.8, which is a high CVSS score.
And no disclaimer in this case at all. So there is some kind of growing understanding that these
vulnerabilities, while they are not as sexy as protocol vulnerabilities, they are not as accessible
as network vulnerabilities, they are interesting and they are dangerous. Another example for the
growing security focus is the Pwn2Own competition that was held in Miami this year. So Pwn2Own
is an organization of competitions that invite hackers to compete on finding specific
vulnerabilities in specific devices. For example, find a remote code execution in a Tesla car.
If you do, you get a lot of money for that. And so the first Pwn2Own competition that was targeted
on ICS products was held just in the beginning of this year, and it had five categories,
and one of which was finding vulnerabilities in ICS project files. And so even an organization
like that, which is very oriented towards security and very up-to-date in terms of understanding the
security world, sets one of the categories in the competition as vulnerabilities in ICS project files.
And not only that, the winner in this category would win $20,000. So the motivation is
not only interest, but also gaining a lot of money. And by the way, there was a winner in
this category. Someone collected this prize, and this category also held a product by Schneider as well,
which we also collected the prize for. So I think at this point, what we can say
is that project files are great for asset management. They are very interesting. The
information they hold are very interesting and valuable to an engineer and to the security
of this network. They're also great for researchers' employment. And what do I mean by that?
My job is based on the fact that these project files are complex. If anyone could just open a
project file and extract the data from it, my day would be a lot less interesting. And so they're
great for me. But also, they might be great for an attacker, not only for recon purposes, for mapping
the network, as we mentioned before, but also because they are vulnerable. And what I would
want to show you is that they're vulnerable, not just in theory. So we saw that there were
vulnerabilities published. But let's do a quick overview of these parts that we saw before,
that comprise a common ICS project file. And as you can remember, we discussed the zip file,
we discussed OLE files, etc. And let's take it step by step. And I will show you that
just in the recent months, vulnerabilities have been published for every part of this project file.
So let's think of it step by step. And we started off with a zip. And what I wanted to show for
zip files is the very common zip slip vulnerability. And so what this actually means is there is no
sanitation on zip paths. But let's explain what this means in a more technical way. So let's have
a look at what the header of the zip file looks like. So take it in for a second, I'll have a drink.
Okay, great. So as you can see, as you can see, a zip file holds a lot of different files within
it, right? When you double click a zip file, it extracts into multiple files and multiple
directories. And the way that the file is saved for real, in its binary data, is that its header
contains the list of files to which we need to extract the information. So for example, this file
will extract information to a directory called example-slash-uex. And another file will be
extracted to example-slash-file1.txt. And another file will be extracted to example-slash-filewithalongname.sql.
So when you double click this file, you will get a new directory called example, and within it,
you will get three files. And that makes sense. And that's just how the zip file header works.
But this also means that if not properly handled, an attacker may use these attributes
of a zip file. And how they may use it? They may employ the special characters that allow
directory traversal. Because this slash dot dot slash means go up one directory. And so instead
of saving the file within the example directory, this will cause the software that extracts this
file to save this file somewhere outside of the targeted directory. And so we may write files
basically to any location we want on the computer on which this file is extracted. And this is a
very common vulnerability. It has been known for years. It has been handled in many products.
But what we see in the ICS domain, unfortunately still, is that some products still do not
sanitize the paths and do not make sure that there is no use of these characters and allow
an attacker to employ this vulnerability and save files basically to any location they want
on the target computer. And saving files on any location sometimes would directly mean
being able to take control of the computer, because you may override some files. You may
save files, for example, like we did here. And you may save files to the startup directory and
save in the store.exe. And that's obviously not something we want. So that's just a very, very
basic vulnerability in zip files that is still very, very common and may happen if the product
does not make sure that the paths within the zip file header are valid. So that's zip files.
But let's take a step in and I'll just show a couple of vulnerabilities that were published
just in the recent months in these exact things. This path reversal CWE means exactly that,
means that someone could use this attribute. And as you can see here, just in the past,
during the past year, several vulnerabilities have been published in this exact method.
So that's a zip file. Now let's have a look at the OLE files that we mentioned that are very
common within zip files. And here I will not go into a lot of details, but as I mentioned before,
OLE files are the files used by office products and, sorry, old office products. And old office
products, we all know that have been vulnerable for years, right? You would not open an email
saying, hey, please download and open this world document I sent you from someone you don't know,
because you know that this could be dangerous. And still, a document from the FBI showed that
the most common used vulnerabilities still today in 2020 are, I think, five of the 10 most common
used vulnerabilities in real life are still vulnerabilities in office files. And so OLE
files, vulnerable. It doesn't matter if you wrap it with Office or wrap it with an ICS engineering
software. They are vulnerable. That's OLE files. Next, let's discuss databases.
And when you think of database and you're a security researcher, the next thing that comes
to your mind is SQL injection. That's, again, a very, very common vulnerability in the handling
of SQL queries when working with databases. And it's very common in the world, and specifically
in ICS software. It still exists. It may exist if the software uses a database to save its
information. So let's take just one example for a vulnerability that was discovered as part of
the Pwn2Own competition by Uri from my team. And what... sorry, by Amir and Sharon from my team.
And what they discovered was that one of these products saves this information within a
database. And if you save... and this database holds the version in which the information was saved.
So if you change the version field to a lower version, then when the software opens this
database, it will run some migration scripts on the file. And what we found was
that you could use one type of SQL injection in these parts and create a full remote code
execution just based on an SQL injection in the database. And what it looks like is, as you can
see, the engineer would double-click the project file, the engineering software would open, and within a second
we will see a notepad pop up. And in this case, notepad, but in a malicious case, it will not be notepad.
It will be some kind of software that might cause damage. So that's databases. Let's go on to binary
formats. And obviously, binary formats are risky because they mean that someone had to write a lot
of code. Someone had to design a format that would be secure enough. And all this work
has been done usually years ago when no one was security-oriented. And so vulnerabilities
in binary formats exist and exist a lot, and we see a lot of them published
on a monthly basis. And so I won't go into details in this case because simply you
can understand that the complexity of a binary format means that many vulnerabilities may be found
within that. For example, just one example here, this article by Ed Kovacs from Security Week
is reviewing a vulnerability published in the Red Lion HMI files that we saw before. So those
compressed files and those Crimson compressed files we saw before, we saw earlier, are vulnerable
to some vulnerabilities that were discovered by security researchers and were published before.
So that's binary formats. Lastly, we said that if you're really lucky,
you would have a text file. And one might think that a text file, how hard can it be?
What can be vulnerable within a text file? And still a vulnerability published by Uri from my
team just a few months ago in one of Siemens's products showed that the parsing of a textual
file within the software may have caused a remote code execution. So again, if you would double
click the project file, code would be executed. And that's even though this file was just a
textual format, the bug was obviously in the parsing of this file. So what we could see is
that taking apart the common ICS project file, you can understand that every part of it may be
vulnerable. And basically what I want to convince you is these vulnerabilities may exist, they're
not something that is out of the ordinary. So let's take one type of project files, and this
would be a project file used by Phoenix Contact software PLCnext. And let's see exactly how this
vulnerability works, just so we can get a hang of how this vulnerability works. And so this
vulnerability was discovered by Amir from my team, and this vulnerability allows
remote code execution when a project is opened in the PLCnext software by Phoenix Contact.
Let's understand how it works. So first of all, this is the software. This is just a screenshot
of the software. As you can see, it holds some information. It shows all the information about
the HMI, the PLC, etc. And this is just how the software looks like. But let's see how the
information is saved behind the scenes. And indeed, in this case, the information is saved in a pcwex
file. And as I mentioned before, the pcwex file is actually just a zip file with a different
extension. And so if you extract it, you can see that there are a few files within this file.
And one of the files that was of interest for us is the project.proj file. And why is that?
The reason for that is that this file is just an XML, a textual file.
But as you can see here, it contains an import line that imports a file from a specified location.
And so what you would do is you would... this line here contains basically a pointer to another file.
And this file will be loaded when the project starts or will be accessed when the project is
loaded. And this file that is pointed to here would be the targets file. And this targets file,
again, is a textual file. But as you can see here now, it gets interesting because it contains the
names of some DLLs that need to be loaded when the project is built. And so what we discovered was
that basically when you open a project file, you... when you open a project file, this whole chain of
events happens. And if you want to be... to think of it from a malicious actor's point of view,
what you would want to do is to be able to send a malicious pcwex file and get the engineer to
open it. And you would change the pointer here to anything you want, basically any other file you
want. And let this other targets file contain a pointer to your malicious DLL. And let's see what
it looks like in real life. So we start again with the same directory structure, because we only
change a bit of lines within the files. And within the project file, we changed it. Instead of using
some kind of environment variable, we'll simply point it to a malicious SMB server that is accessible
to the victim's machine. So we don't have to drop this file ahead on the victim's machine.
All we have to do is make the victim's machine approach us and request for the malicious targets
file. And within the targets file, again, what we would do is we would point to a malicious DLL
that is used, that is loaded when the project is built. And so what happens basically when the
project is open, that the software is automatically building the project. And so they access this
project file, this project.proj file, and collect the malicious.targets file from our server.
And based on this malicious.targets file, they will collect the DLL
again from our server and execute it. And once they've done that, basically, we ran our own DLL
on the remote machine with the permissions of the software, and we've taken over the control.
And that's the whole vulnerability. And that's pretty cool, in my opinion. And obviously,
this vulnerability was disclosed to Phoenix, and we would like to acknowledge their quick
remediation of that. It took, I think, less than two months between the time we disclosed this
vulnerability to Phoenix and the time they released the fixed version and its advisory,
which is very nice and not very common in the ICS domain. So we would like to thank Phoenix
for fixing this in such a hurry. Cool. So what did we do so far? We showed that
those project files are interesting, and we showed that they are vulnerable. We showed that you can
find vulnerabilities in them. And some of these vulnerabilities, you don't even have to work very
hard in order to explain. So let's complete the last piece of the puzzle. The last piece of the
puzzle would be how I can use these vulnerabilities in order to take over an engineer's computer.
Because if you think of a protocol vulnerability, you know that the PLC is there. You know that
you are here. All you have to do is communicate with the PLC, and you are done. But in the case
of a project file, you know that the engineer is here. You know that you are here, but you want to
get the engineer to open a project file of your own. So the attack vector here is something that
I need to convince you that exists. So we had a look, and we tried to think what ways could be
used to get a victim engineer to open an ICS project file. Because you know that when someone
sends you a doc file, as I mentioned before, via email, someone you don't know, you will probably
be suspicious about it and not do anything with that. But if you're an OT engineer and they send
you a Rockwell ACD file or any other type of ICS engineering file, then you might be curious. This
is your world. You're interested. You want to understand what's going on. You will want to open
this file. You will be curious. So instead of sending you a doc file, in theory, the malicious
actor could send you an ACD file or a project file and get you to open that. It would be more likely
that you do. And this type of phishing campaigns happens. In the COVID-19 world, you know that
and many papers have been published on that, that the fact that phishing is on
the rise and targeted phishing towards ICS industries is on the rise. So as you can see here,
this may be used as a phishing campaign that is very targeted and very specific
towards OT engineers.
Sorry, and not only phishing campaigns or not only phishing campaigns via email, what we thought
next was, let's check the forums, the support forums in the ICS domain, because we know these
support forums are very, very, in very, very common use. And many people use them to ask questions,
to help other people to get some support, both the vendors' own forums and the public forums.
So we had a look at these forums and we looked for people who might have posted
these project files and had a look at what they have done. And so, for example, this is just
one message from a forum that we found. I have an ACD file, but I do not have the software to
read the controller tags. Can anyone please help me convert this file into a PDF? And they published
with this message, they published an ACD file. And what you could see in the comments section
is that many, many people did download this file and did open this file and help this person. And
obviously, this was the happy case where someone did need help and many people did help him. But if
it was a malicious case, then this question could have caught many ICS engineers and have taken
control over the computer if this was a malicious case. So this attack vector of getting an ICS
engineer to open a project file, I think, may happen. It's really real, either as part of a
request or anything like that. And the reason this is very critical, and more critical than
using just a doc file, is that this engineer who sent an ICS project file via email from
the internet, they will open it on their computer. And this computer, you know that this computer, by
definition, has access to the shop floor, has access to the actual physical devices. Whereas
if this was just a Microsoft Word document, this engineer might have opened it on their own
computer, which is not connected to anything interesting. But if you provide the engineer with
the project file, they would take it to the computer that is connected to the shop floor,
because it has the engineering software installed on it. So basically, the hacker, with just one
step, got access not only to an engineer's computer, but to the actual critical engineer
computer and to the actual critical network. And so, hopefully, what I could convince you with
along this talk was that ICS project files, they are very interesting.
They allow you great visibility into a network and great understanding of your network. And so,
I don't want anyone to go home and delete all your project files, right? Because you have to
keep working, and this may provide you of great value if you handle these files right. Obviously,
you also have to secure your files to make sure that no malicious actor gains access to those
files as well. But they are very important. But on the other side, you have to be aware
that these project files can be just as malicious as a doc file. And this means that you don't want
to open any ICS project file that is uploaded to a support forum or to anything like that.
And actually, these files may be even more dangerous than these doc files, because what
we said just a minute ago, that they will provide the attacker with access directly to the critical
network. So, these files for an attacker actually are a great way to spread through phishing
campaigns that are targeted, that are going directly to the ICS engineer, not just to anywhere
around the world. And so, they're very critical in that. And they will get this attacker a foothold
in the ICS network. And so, the bottom line here of this talk is just use these ICS project files
to gain visibility into your network. And that is great. But be suspicious of any ICS project
file that might have been sent to you, and that might pose risks to your network.
And that's it. Thank you very much, and have a great conference.