- Hello, everyone.
I am Mars from TXOne Networks,
and we are happy to have the opportunity
to share our research results on the DEF CON 29 stage.
In this session, we will discuss the ecosystem
of ICS and SCADA, and more deeply focus
on the Mitsubishi Electric's communication protocols.
And please allow me to quickly introduce TXOne.
TXOne is a subsidiary company under Trend Micro.
We focus on providing cyber defense
and visibility for operational technology.
And currently, I'm the threat researcher for TXOne.
I'm focused on IoT, ICS, and SCADA,
enterprise-related security and threat research,
and also shared many results
of my security research
at the major cybersecurity conferences,
such as Black Hat, HITCON, SecTor,
Hack In The Box Conference,
and other major cybersecurity conference.
I'm also the general coordinator
of the Hacks in Taiwan Conference, HITCON 2021.
And my colleague Selmon,
Selmon very specialized in IT and SCADA protocol parsing,
and Linux kernel programming.
He also has both speaking experience
at the global conference,
such as CYBERSEC, HITCON, Hack In The Box Conference,
and also made a repo for regular ICS research.
And today's outline, and first we will discuss modern ICS
and SCADA ecosystem, and then move on to the problem
of Mitsubishi ecosystem,
including to how we, how to analyze
and successfully take over the entire ecosystems.
Because Mitsubishi is now very actively
facing this issue of our finding,
and we will also share the process
of our content with Mitsubishi,
and show why we decided to share our finding
based on the public's right to know.
And finally, we will also share,
let you know how to perform mitigation.
And first one, Modern ICS/SCADA Ecosystem Overview.
Mitsubishi is world's third largest
industrial control manufacturers by market value
with a global market share of more than 10%.
So you will see the top three,
and then so very powerful percentage
in the global market here.
And also, ordered by the net annually sales revenue
in the industrial automation status,
Mitsubishi is also among the top three,
the top three here.
You will see here.
And at the same time, it is also ranked third
among the most popular PLCs
with the commercial status entities.
In the previous slide, we can see
that Mitsubishi has performed very well in this field.
And we're also very interested
about the Mitsubishi ecosystem scope.
So let's take a look, close look,
at the scope of Mitsubishi PLC series.
And Mitsubishi can basically cover
any size, system size, from small to large,
and they provide different levels of PLC
for different system size.
So from the slide you will see
from small size to large size
the MELSEC-F, iQ-F, L, Q,
or iQ-R are the small to large order
of land that can cover that.
And also, but you will be interested in one more thing.
It's where are their PLCs used.
So based on Mitsubishi's official statement
and our own observations,
Mitsubishi's PLC's very powerful
and widely in use by a range of verticals,
including automotive, automated,
or warehoused, food and beverage,
semiconductor, general automation,
chemical, FPD, inspection machines,
and (mumbles) land and including the building automation,
injection molding, printing, machine tools,
and many more of them use the Mitsubishi PLCs.
It's very widely used,
and they covered all critical infrastructure,
many infrastructure, such as we daily use
like power, water, wastewater, and so on,
and it's very close with people's life.
You just imagine
whether those industry are close tied
into your daily life, maybe for security issues,
occupying critical devices,
like the maintenance (mumbles) industry.
The attacks can disrupt, or control our asset,
and may will be very dangerous
and very powerful and huge.
So you should take care of these.
Initial, before we performed this research,
we reviewed previous very powerful
industrial security research,
and we noticed something important.
Almost no one conducted research on Mitsubishi.
Most of the related research is
instead focused on Siemens S7.
So it was in Black Hat 2019, 2017, 2016, 2010, '11
focused on Siemens' devices.
Or even then only focused on Siemens,
about some other part
have nothing to do with the communication protocols,
like ICS-targeted malware,
or attack vectors in different centers.
So we believe this is,
we revealed it of opportunity to work in depth
with the Mitsubishi ecosystems.
And also, we also more review
the Mitsubishi vulnerabilities.
It is a very important thing, so we reviewed it,
and has already announced
the vulnerability in the PAC,
in maybe one years ago, a few months ago.
Also, here this table shows some examples.
But there are many more,
and we have found that most of the published vulnerabilities
are only specific devices, modules, softwares,
and do not specifically address issues
in their communication protocols itself.
So now that we have introduced the starting perspective
of our research, let's take a look
of the three different ICS ecosystems.
And how does the ecosystem
of critical infrastructure control system look like?
Our first example is Modbus,
and you will see that HMI appears.
Engineering workstation offline use
Modbus TCP communications,
and only the PLC and with field devices use
the Modbus RTU, or ASCII.
Well, usually, it's a secure line based on TCP/IP,
not based on SNI Ethernet,
but they were something different.
But to focus on the Modbus TCP layout,
something different occurring to the different function
implemented by different manufacturers,
or licensed vendors.
But basically, the native functions are quite limited.
And also, second example is Siemens.
So in Siemens, it provide their own private protocol.
Siemens S7, S7+ has already the strong-handed security
to a certain extent by applying
in depth research from many researchers.
So while I dare not say that this protocol is secure,
but I must say its security is
already much better in conversation
to other ICS protocols.
So we will say, oh, Siemens is a good,
do a good job for cybersecurity than other ICS vendors.
But finally, what about Mitsubishi?
And between the HMI and PLC,
it support a wider range of communication protocols,
such as SLMP, Modbus, TCP, and Ethernet/ IP
based on different amount network modules
in order to support their company's abilities
with a variety of assets.
And from the perspective of attacker,
if you come, cut from the HMI,
you must understand that
various protocols can be used in your attack.
But for their PLC engineering workstation,
they use the MELSOFT,
and MELSOFT, a private protocol,
is used to communicate between
engineering workstation and PLC,
and if someone can take over MELSOFT protocol,
they can compromise all Mitsubishi PLCs,
and master the entire ecosystem,
and we were able to actually publish this.
Now, to have a fun part, let's dissect
and compromise Mitsubishi ecosystems.
So for attacker, if we can discover a vulnerability
in MELSOFT, and we can basically take over
Mitsubishi ecosystem completely,
and we can fake an (mumbles).
Engineering workstation to pass the command
under the PLC, so it does whatever we want it do that.
So we configure it exactly.
We've used the MELSOFT protocol to communicate with the PLC.
And also, yes, MELSOFT have authentication mechanism,
but this authentication mechanism is not,
is very, very weak.
In other words, as long as we can pass the authentication,
then we can take over everything.
And as you can see, this is just a few handshake process
between the engineering workstation and PLC you see,
and at beginning of the entire authentication process
engineering will, engineering workstation will send
a challenge request, it's message one, to the PLC.
PLC will return the random 10-byte challenge code
to engineering workstation.
And then engineering workstation, EWS,
will do the calculation based
on this 10-byte challenge code,
and send back the 32-byte code to the PLC.
And then confirm whatever, or not
if has passed the authentication.
How we have to do this,
and what we have to do is to reverse the calculation process
of these 32-bytes, and let's edit the things we need to do.
Then we want to find out is something tricky,
or something interesting in that part.
So how can we reverse?
Their engineering workstation software is our goal,
and GxWorks2 and GxWorks3,
and because they support different PLC type and PLC modules
we know from small to large.
So you can think of GxWorks3 is the newest,
and GxWorks2 is older, but you can see this,
and let's take this apart.
But I will say on the new application is something different
in the other, some backend services.
And so, now we will start our reverse engineering general.
But there are many, many steps,
but they are not too complicated,
but all of them are exchanges between the various bits,
or operations between arrays.
After receiving the random 10-byte challenge code,
the first thing is engineering workstation will calculate
the exclusive OR operation
with a challenge code and an execution xor_base_hex.
Here you will see that from the red.
You ask for the blah, blah, blah here in step one,
and they will change in Xored_buffer place,
so it'll change the place state.
So it's step two.
And into the step three,
it will convert the tmp_buf to the shortened variable,
and verify PLC 10-byte challenge code,
and sum the tmp_buf.
We believe this behavior is used
to confirm the integrated of the 10-bytes challenge codes,
make sure that it not be modified
by other people, or attacks.
So they will calculate this.
And after that, there were, yeah,
engineering workstation will retrieve
the four short variable to integer variables,
and then go to the function, sub 62C3E.
So go to deeper to the sub-function.
In this moment that we were,
I will say there are many, many sub-function,
and got your layer, go by layer,
so just be patient.
It should (mumbles),
because there are many, many operations
for creating these 32-byte response.
So also in step six, after land in the function 62C3E
and we'll use the predefined 32-byte code
to generate the 32-byte passcode.
And you will see the predefined 32 bytes right here.
But I will say these 32-byte array will be based
on the different PLC model, right,
and get a different value.
So you need to trace the ID spawned by one.
If you want to attack a A model, you need to trace A, right?
Yeah, and also on step seven,
where I'd like to generate the 64-byte output buffers.
So you will see the pseudocode here,
and (mumbles) will put it here.
And also, after that, it just had the calculations,
but after they will generate the 64-byte array
with the value 0x36,
and for step nine, and perform the exclusive OR
on the first 32 bytes, and the 5cdb array,
and then jump to the function sub 62860.
So you will see the left light of here.
Here, here.
Yeah, so you see here.
Okay, and in step 10,
they will generate a code to another function.
Yeah, yeah, 62860 here,
and generate another 104-bytes array,
and copy the value from right here
to the first 32-byte parts here.
So the value could be five byte at least the variable,
but just yeah, I'm gonna go through this,
and then copy the 64 bytes from right.
Yeah, 100 bytes, and fill the zero in the last eight bytes,
and show on this table.
So you can quickly through and query,
understanding the 104-byte, or greater of the list,
including some things here.
So and then, go down to another.
Go back to the sub-function 62C3E
and jump to sub-function 62B7B,
and jump to the sub-function 6289B
to handle the last eight byte of the 100-bytes array.
And set the last eight bytes
as a two integer variable,
and add the value 0x40.
So you will see this.
And also, after that, we'll do the, yeah,
another, after another
on sub-function 628C7
after 6289B.
And it will run the calculation,
and update the first 32
bytes of the 100-bytes array.
But it just had a huge calculation,
and you know, just quickly goes away,
yeah, because no very special things here.
And also, it's queued the sub-function 62B7B again,
and updated 104-bytes array
based on the computed challenge code,
and therefore go to step 15.
It's queued up some function
on 62BC6.
So we'll see go here,
then update the value in offset 0x30.
This is at 0x80
from the 104-byte array,
and add an offset 0x60,
and you will see there's many sub-function
in the sub-function of 62BC6.
So and then we go down layer,
and to calculate the, I'll point out these functions,
and we read in some function
to help you understand a lot of things, like the arrays.
And also, yeah,
in step six, function,
sub-function 62ACS
on the update the 104bytes_array buffer
from offset 0x31,
and set the 27 bytes to zero,
and offset 0x60
add the value 0x27.
And then, update the 104-byte array buffer used to,
yeah, but we will, before that,
you will see the 62AC7 function
being already used in the previous function.
So it's used to just update first 32 byte,
just so we're not duplicating
these two repeatedly on the part.
And go down later to step 17,
it is a function also update the 104-byte array buffer
from offset 0x58.
Set the four bytes to zero.
Add an offset 0x64 to a integer variable
and left-shift three bit,
and swap it with the offset 0x5c.
For offset 0x50,
add 0x8 here.
And then, also still in the same sub-function,
but we'll jump to another sub-function, to 62B49,
and update to 104-byte array
to 136-byte.
Yeah, you will see here,
where the first 32 bytes was eight integers,
and add the 32 bytes offset
0x0104,
and then swap it.
So you'll have it right here.
And about step 19,
the offset 0x136
set 0x5c bytes value
to 0x40.
The byte array is 200 bytes now.
So we will calculate later for it
based on this 200-byte amount.
And step 20, the loop,
you will see the (mumbles) for loop.
We see exclusive OR, the last 32 byte
in the 200 byte array within Output,
and storing to the 200 byte array, right?
And the following function is just repeat
the same function behavior
based on this, and just based,
just use this 200 bytes to calculate it.
So after all of our calculations,
and getting the final 200 bytes
and the first 32 bytes is
the MELSOFT authentication function need.
So, you notice they just catch
the first 32 bytes from the final 200 bytes,
and then sent back to the PLC,
and just passed the authentication.
And also, at this part I think
you already know how to trick
MELSOFT authentication mechanism,
but I want to emphasize one thing is on network traffic
kind of is absolutely indispensable to the latest research,
because when we do a lot of reverse engineering,
but listen, protocol is network protocol.
So you cannot without any tools
help you to analyze the network traffic.
So we believe this, if we combine them,
we can totally take over it, and more easily.
So for this purpose, we built the Wireshark Lua plugin
for the MELSOFT protocol,
and also we will show this protocol later
for our demo.
And we will kind of share our plugins for the MELSOFT
and can help us to recognize understanding the Wireshark
and the MELSOFT protocol.
And now, we come to the fun part.
In our scenario we want to take over the entire PLC,
the Mitsubishi ecosystem, right?
So we built this scenario.
It's overwriting the PLC program,
and it's our goal, because after the bypass authentication,
everything we can do later.
But we want to overwrite in the PLC program.
Right, it's our goal.
Just a demo, so you can see that,
and if we can bypass an authentication,
and successfully overwrite the PLC program,
and we can perform any other function we want to perform.
And so, that's a look how to overwrite the process.
So here, we just let you know
how to quickly go through this handshake process,
and we will, later we will step-by-step
to let you know with the Wireshark screenshot
to describe this, the function behavior.
So you will see the message one is used
to send the challenge code,
and back to the 10-byte challenge code from PLC,
and it message you, and message three were sent
to send us our authentication request
with the 32-byte challenge code,
so to the PLC, and pass an authentication.
So after message four,
an attacker can do anything they want to do.
And you likely remote stopped,
but here, just if you need to overwrite the PLC program,
you need to do remote stop first,
and open the file, and search the file,
and read the PLC program file here,
and after that, you need to write data,
the data, the byte you want to write to the file,
so with the message 13.
And after that, update the file size with message 15.
Change, modify the file creation date
and time to close file,
and write a file modification to storage.
After that, you're already done with all the file operations
and then you just need to remote run it.
You can run the PLC program,
which you replace it.
So here is this totally handshake process.
Quickly go through this.
Just keep in mind,
and you will know our whole process is like this.
As well, we also have the Wireshark screenshot
for follow-up detail and step-by-step.
So the first, the message one
the engineering workstation will send to the PLC
a challenge code 0x5a0000ff
to get the challenge code.
This is a fixed number, it's a fixed value,
and it never changed,
and when PLC receive this, it will generate
the 10-bytes challenge code
to the engineering workstation.
And engineering workstation will,
our fake engineering workstation will calculate
the the 32 bytes of payload that will you see here.
You will see here,
so where we'll payload to the PLC,
and when PLC receive this 32-byte payload,
and will integrate it, and then pass an authentication.
So after that, if the message for the error code
in message four is 0x0000,
it means this is success.
If it is another value, and authentication failed,
so after that, we saw that.
We see that it is very exciting,
because we successfully to pass an authentication,
and then from message five,
the attacker can do anything we want to do.
So we do a remote stop with this function code,
because we want to overwrite the PLC program.
So you need to stop the PLC now.
You can operate the program, right?
So get a function code 0000 for you,
and then you can send a request to,
you want to open the PLC program file,
but you don't know where is the PLC program.
Find out where, so you send another comment is
you want to find, you want to search this file.
You will see that you want to search
for MAIN.QPG PLC program file here.
Okay, so get a response,
and then send the request to message 11 to read file.
We want to read the PLC program file MAIN.QPG,
and get a response, successfully read, successfully read,
and send the MELSOFT request
with message 13.
You want to write your data to file,
and this method repeated tries,
because it's based on your data,
how big your data your want to write into the file.
But we want to replace,
we want to overwrite in the PLC program, so here.
Just like this.
So we'll give two tries to file one, file two,
and get the successfully error code.
And send the update, another function code update
of file size, because you already changed the files,
and the file size need to be changed.
And then,
we send them a message searching to modify
the file creation date and time of at least this file.
Okay, and send a close file.
So you already close file.
Meanwhile, you see you already write
all the, how you want to write your PLC program is done.
And modify the, write the file modification
to the storage.
Get that error for you again,
and now, you can remote run.
You can run the program,
and if you run it, you can (mumbles) to run
the PLC program you overwrited.
So that is successfully.
Now, we show another demo
of our demo of these procedures.
So this demo will just show whole process
of our previous slides for overwriting PLC program,
and normal status here is
normal running, everything is normal.
Green light of PLC running.
And in our text area, we overwrite the PLC program.
So...
Download the PLC program to PLC will make the PLC
to stop operations state,
because it's the empty PLC program.
But also if you want to modify a specific point of the PLC,
you can change this.
So in here you'll see the PLC already be stopped,
because we update, we download the empty PLC program
to the PLC.
So also you will see here,
if we use (mumbles) organization to view
the PLC program, you will see
before we overwrite the PLC program,
it look like this.
It's very normal status, and average ladder logic.
Ladder logic very normal.
After we overwrite it, it's empty, totally empty.
So we can really make huge some impact on this site
if you can change everything you want to do.
But how about a lot of potential impact on these attacks
if you, when we use the MELSOFT protocol,
and according also, right, we know,
generally speaking of PLC series
of Mitsubishi were impaired by the MELSOFT protocol,
because they use MELSOFT to communicate
between engineering workstation and a PLC.
Also, some newest PLC will (mumbles) it
to MELSOFT authentication,
but if you know attacker know the MELSOFT protocol,
they can take over the devices directly.
It's very easy.
And also, we will say other people will study,
you know, SLMP protocols,
and we will say this is just small part,
and also we will discuss an issue later,
because we will share our reporting
of the vulnerability process with Mitsubishi.
And also, the potential impact of the attack
using the MELSOFT protocols,
so not only many things you can do,
like remote run, remote stop,
or to interrupt the process,
or you can overwrite the previous program, like us,
or you can write and read and (mumbles) data
to change the small part control process,
and also you can move the malicious file in the PLC,
and generate that to the PL file.
So we know you will, something understanding about it,
so we provided a common baseline
based on the MITRE ATT&CK Matrix for ICS,
and basically the impact we can achieve
just by taking over the MELSOFT protocol is rich,
and depending on what the attacks want to achieve.
So you will see the part is including
manipulation of control, denial of control,
and loss of control
both included with our attack scope.
So now, so as we mentioned before,
we say Mitsubishi is now already facing these issues.
So we want to highlight, because it's not a problem
only for Mitsubishi.
Other vendors we contact, we meet
also have some of this attitude to very,
not very attitude to handle the vulnerabilities.
But we want to highlight it,
just we want to keep everyone know
about this very serious thing.
So here is our timeline for we get our first reply
from the vendors.
So on May 30, 2020,
this is the first time the vendor replied,
and when we notified that.
And the vendor replies that the authentication process
we point out is not to protect the customer's security,
but to prevent connection to devices
of other companies, and more plainly this,
that it's not a vulnerability from the vendor's side,
from the vendor perspective.
However, regardless of the original purpose,
this authentication process does have problems.
Attacks can use it well to perform the various operations.
Our research showed how this is a severe risk.
So we know the vendor don't think,
this is not a vulnerability.
This is like a feature, just prevent
other vendors' connection.
But we don't think so.
And after the vendors first replied,
we write back later the message to let them know
why we think this is a vulnerability,
and this is very serious, and just how we find it,
and as well as how it can be exploited.
So in response, and we said this is unfair reply,
and we want to highlight it and point out
we can successfully bypass this authentication.
We can make such a impact.
You should know.
As a vendor, you should have
some security awareness of this.
Should not avoid.
And also it is a part of our second reply
that we want to also explain what happens
when the authentication is not passed,
and basically we think this is need to be addressed,
and think likely to lead to very serious dangers
when their (mumbles) exploited.
So here, okay, and the vendor declined on that part,
because we highlight the scope from MELSOFT and SLMP,
and they say SLMP does not require the authentication, yeah.
After our modification,
it is now required authentication of SLMP.
I would like point out this one point,
since it's this is not actually more dangerous
without authentication between HMI and PLC,
and attacker can easy to attack PLC.
I know that it's a legacy protocol
usually you see for, this protocol for ICS
and offline are not securely designed.
But I think it's not a reason for not to focus on this,
not be able to, not face the security issue.
And these functions have some limitation
compared with MELSOFT here.
So we will say the SLMP is a subset of MELSOFT,
and we can provide attacks with richer results
to compromise devices.
And also, this is a part of our,
on some question we want to, yeah, render repairs.
And here, we are (mumbles)
the last time I replied.
Basically, we want to lay out how much information
we have addressed as to the exploit.
From forging the engineering workstation,
we can successfully read and write everything we want,
and should not, this behavior should not be
used by the unauthorized user,
or attacks to do this behavior.
And so, we said yeah,
if we cannot upload at least some of the material,
we still just, we still want to highlight the issue,
and not compare with SLMP, because this is independent.
SLMP is SLMP, and MELSOFT is MELSOFT.
But they said yeah, it is, in our Q series,
it is possible to use SLMP to operate the MAIN.QPG
and just as possible to operate
through forging engineering workstation.
So they say yeah, our SLMP does not support
user to operate its program file,
but SLMP will allow that authentication.
So everything can do that, so no security issue.
This is very, yeah, I know, well, unbelievable,
but we know this is the vendor's perspective,
because manufacture is different with the security guys.
So also, and later I decide to close this case,
because the vendor find out,
and totally does not recognize this as a vulnerability,
but we think this is a vulnerability.
And after a few days, because we also,
in here, we also sent our,
we walked through procedures.
We want to let people know.
We want to share our finding to other people too
in a cybersecurity conference.
So after go Mitsubishi,
vendor say yeah, another,
we receive another reply from vendors
and hoping that we would indicate
and first say this is not a vulnerability,
this issue is not a vulnerability in Mitsubishi products.
So of course, yes, we respect the vendors say this,
because we know, we can only understand
that a lot of vendors, it's not easy.
You need to build it in also huge systems security devices.
But we know there's some conflict
with the security people and manufacturers.
So we respect the vendors, I have to say that.
And so, we will say,
so we say this is conflicted
with the security perspective
and the manufacturer's perspective.
So this issue is not a vulnerability
in Mitsubishi products from vendor's perspective.
But we still hope that this issue can be remedied
before it lead to a problem for work-side stakeholders.
So for that reason,
let's take a look how to handle this issue.
Okay, so there are short-term and medium to long-terms.
For short-term, you need to mitigate your environment.
You need to detecting, you need to protecting
your ICS and SCADA protocols.
Even they are legacy protocol,
they are the security they decide.
But you should try to protect your environment.
Basically, sometimes vendors cannot patch it,
or vendor would not patch,
because they may want to deliver new versions maybe.
And also, for these reasons,
only for MELSOFT we focus on this.
So we provide the Lua plugin for analyzing MELSOFT protocol
and we also provide Snort rules.
It is IDS new rule, IDS, IPS rules,
and for open source, and this can help you
to detecting and to protecting MELSOFT traffic.
So something like this.
Here is our rule set.
You can just copy this to your Snort rule list,
and then run it, and it can help you to detect
and to protect some specific
MELSOFT communication, like MELSOFT authentication,
remote stop, remote run, or write files on this behavior,
and also you can check this is how to,
oh yeah, a rule is useful.
And also, last part is,
yeah, the mid to long-term complete planning.
We want to help you to think, yeah.
We know the ICS vendor usually don't have
the security awareness.
We face many, many ICS vendor lately
usually don't have the security awareness.
OT guys, ICS vendors, ICS manufacturers,
they don't have the security awareness.
So I think that is first thing
that you should be able to allow security awareness.
And you can each now try to build
your defense in depth environment for outside,
like a simulated attack from the outside,
and what they want to do,
and how you build your security environment
from outside with some security devices,
you know, firewall, or IPS, maybe,
but still based on your environment.
And also, there is a security design in the protocol,
or other components from inside.
So it's based on the ICS vendors.
They need to, they should be
doing the security side
that prevent the vulnerability happening
in their components, or service,
because other people, power, water they use
will be more secure.
And then you can secure your ICS and SCADA ecosystem
more securely in the future.
And often we said in Oracle,
there was, they say our priority
is keep the operation running.
Yeah, we believe.
But we more believe is the near future
you should keep your operation secured strongly,
because attacker is more and more,
they try to compromise
more and more infrastructure environment.
We cannot overlook it.
We should take a serious (mumbles).
So that is my presentation, and thank you for listening,
and if you do have any questions,
I'd welcome, and coming in the future,
we'll (mumbles) websites, and we are welcome.
And thank you for listening, again, thank you.