36C3 - A Deep Dive Into Unconstrained Code Execution on Siemens S7 PLCs

36c3 prerol music

Herald: So, Siemens recently decided to
add some security feature to the PLC. And

today we have Tobias and Ali and they will
be sort of.. telling us what they managed

to find. This PLC. They both come from
Ruhr Universität Bochum. Tobias is a

recent acquisition as a doctoral student.
And Ali is a postdoc. So, uh, let's give

them a hand.

applause

Ali: Hmm, where is our slide?
Tobias: Presentation mode?

Ali: Yes. OK. Welcome to our talk. A deep
dive into on concentrate code execution in

Siemens S7 PLCs. My name is Ali Abbasi and
as mentioned before, I'm a postdoc at

chair of System Security at Ruhr
University Boch and here's my colleague.

Tobias: I am Tobias or Tobi. I'm very
glad to be here. It's my fifth time at the

Congress and now finally able to give back
in a way. So I'm very excited about that.

So let's get into it. So first about the
plan of the talk. We want to give you a

little bit of a background of what PLCs,
which is programmable logic controllers

are all about, why we might want to use
them and in what kind of setting. And then

we want to go into the specifics of PLCs
in the Siemens case. First we look a bit

at the hardware and then at the software
afterwards and the different findings that

we had. At the end, we would show a
demonstration of what we're able to

achieve and conclude with some remarks. So
first of all, process automation. So we

all know it. Or maybe we do it ourselves
or we know somebody who does it. We put in

some devices in our smart home, if we call
it smart already. And we try to automate

different targets on different things to
make our lives easier. Things like turning

up and down the heat. We might not want to
do that our own. We might not want to

overheat or under heat. And what we do is
basically have some sensory systems inside

our homes, as well as some devices that
interact with those sensors. In this case,

we might have a thermostat and a heater
and we want to adjust our temperature

based on the thermostat. They're pretty
simplistic solutions like this for a smart

home. But what we do if we have very
complex control loops for example. Here we

can see on the left bottom corner a pretty
complex looking picture, some operating

operators sitting in front of what we call
an HMI a human machine interface, which is

basically an aggregation of all the
information of things that go on in a

factory, for example. We need different
sensors and this factory and we need to

steer different motors and stuff like
this. So we need things in the middle to

kind of control all of this. And we do
this using PLCs and we can see a setup how

it could look like. So basically have a
set of inputs as we talked about and a set

of outputs. And we have some logic going
on in the middle. And what we typically

deploy is a PLC a programable logic
controller and some logic in the middle.

There are different technologies that can
be used, for example, structure, text or

letter logic which gets downloaded onto
the PLC and then which steers outputs

based on the inputs that it gets. You can
see some applications of this kind of

thing. For example, a chemical power
plant, chemical plant, an electric grid or

some manufacturing. Some of those
components are pretty critical to the

workings. Even either we see it in the
everyday lives and sometimes we don't

really see it. But they are in the
steering, everything in the background and

we really don't want those systems to get
compromised. For example, if you went onto

Google and looked something about
disasters and chemical plants, you could

see melted down plants just because of
some mis.. malfunction in the system or

so. And we really don't want this to
happen. Neither an accidental but also not

a malicious basis. And this is why we want
to secure all the processes going on in

factories and the like. We've seen some of
the recent attacks. So it started kind of

in 1999 with a first initial
reconnaissance based mainly. And then we

had some more advanced attacks in 2010,
for example, where we saw Stuxnet, which

was very much really intricate operation.
If you think about it on a technical

level, what all went into it. What
different skill sets were involved. It's

pretty impressive. And then in the more
recent time we had some issues in the

Ukrainian power grid, which in 2015
and '16 just before Christmas, some lights

went out for quite a while in some cities
there. So quite a bit of impact. So to

give you a bit of impact, a background on
Siemens PLCs here when it comes to market

shares. We can see that together with
Rockwood Automation, Siemens actually has

more than 50 percent market share in the
market. And obviously, if we take out some

devices that introduce some security, it
would be interesting to look at those with

the biggest market share. This is what we
did here in the Siemens case. Here we can

see the actual PLCs that we will focus on
in this talk, which is the Siemens S7-1200

PLC. It's one of the smaller PLCs, not
quite the smallest, there is the logo as

well, which is more of a playing around
example, but this is the one that it's

still pretty accessible to researchers in
terms of costs. So it's like 250 for the

PLC. Then if you need a power supply, it
can add the same. So as long as you don't

break too many, spoiler, we broke quite
some or you don't drop them or something

like this, then you're pretty fine so you
can kind of get the resources to play with

those devices. We have different
applications and we talked about them

before. So here is what an unboxing of a
Siemens 7 1200 PLC would look like. We

have the top view here on the left
picture. It's only one of different PCBs

which are layered on to each other in this
case. But the real magic goes on in the

top PCB, which is the green one that we
see here. Looking at it a bit more in more

detail. We have the top view on the left
side, which shows the different components

that really make the PLC. Take, for
example, the ARM CPU that we have or

different input outputs that we can
connect to a PLC, as we talked about

before, which they need in order to steer
different parts of the system. And then we

have the flash chip on the top side as
well, which is a big flash chip holding

the firmware off the actual PLCs, which we
will talk about a bit more in detail

later. On the flip side, we have on the
right picture the bottom side of the first

layer PCB. And as we can see here, this is
where the bootloader chip resides, which

is an SPI flashchip of four megabytes
owning the code of the Siemens PLC

bootloader. Here we wanted to have a
detailed view on what the actual

processing unit inside this board actually
looks like and what you can do if you want

really want to find out you can do some
decapping. And that's what we see here.

The result of this, we can see that at the
core of it, it's a renaissance ARM

Cortex-R4 for from 2010. And if you
afterwards are more juggling with the

software side of things, you may also want
to find out the actual revision number,

what it supports inside the ARM standard.
And what you can do there is use a special

instruction which resides in the ARM
instruction set and you can decode the

different bits on it, which we did here,
which you can see here for reference. So

if you really want to know what's going
on, you can take apart those bits and make

sure you're actually working with the
hardware that you expect to be working

with. So here's where we come to the
memory part of the hardware and this is

where I leave you over to Ali.
Ali: Thanks. Now that Tobias like unboxed

the PLC for us now I'm going to talk about
quirks and features in the PLC. So as

mentioned before, it's Cortex-R4 revision
3. It's a big endian instruction set and

it's also only have MPU. So there is no
visual memory basically, there are

multiple ram sizes depending on which year
you bought it or which variant of the S7

1200 you buy and also multiple SPI flash
and multiple different types of NAND

flashes. The most significant one
difference is like in the RAM, which

sometimes they use Wingbond and sometimes
they use Micron Technologies, recently

Micron Technologies RAM. It is LPDDR1 RAM.
We expect the SPI Flash for bootloader. So

again, depending on the variance between
one to four megabytes SPI flash, it

contains different banks of each sized 512
kbytes. And basically what the bootloader

does is that's beside the typical actions
of the bootloader, which is like

configuring your hardware is like
verifying the integrity of the firmware

before it being loaded. So we actually
need some X-ray tomography of the PLC. So

it's basically 3D. So the PCB is basically
rotating here because we wanted to also do

some hardware reverse engineering part.
And somebody in university had something,

so we didn't have to go to our dentist for
X-ray. So here is like a quick 15 minutes

X-ray, which is not that good. But once
you go in deep, eventually what you will

have is like this and you can actually
just it's like a software animation. You

can go inside PCB and see all the layers.
It's like amazing. So it's up for PCB

layer. And so besides, VCC and GND, you
need two layers of PCB connection

basically. So let's look at the start up
process. Again. Start up as usual. Some

hardware configuration happens. So
vectoring trap controller, for example,

like lots of this handlers for different
modes in ARM and then CRC check some of

the bootloader itself, which is easily
bypassed over because you can just

overwrite the CRC. Then the bootloader,
especially in the 2017, 2018 variant of

the Siemens PLC, allows you to overwrite
the SPI flash. And also eventually we

check the CRC checksum of the firmware
before basically loading it. The size of

the bootloader itself is like 128 kbyte,
it is really even less than that because

half of it is just like 0xff. Siemens
multiple times changed, they had different

version. I think in two years we saw three
variants or four variants of the

bootloader. So it was evolving. It was not
something that's everybody forgotten about

it. So generally as mentioned, so you have
part this first stage of hardware

initialization and then basically bringing
the bootloader to the RAM and basically

checking the bootloader CRC checksum. So
make sure that it's not manipulated, which

again is it can be bypassed. And then a
second stage of the hardware

initialization happens. And then at this
moment, it waits for a specific command

for half a second. And if it receives this
command it goes to another mode, which

we'll discuss later. Otherwise, it
basically prepares some CRC checksum table

for the firmware and then it tries to
load the firmware and then eventually

just removes the memory barrier the stage
1 instruction those who knows about ARM.

And basically map the firmware
to the memory.

So the name of the operating system, it

was not mentioned before, it's ADONIS. We
know it from different from different

ways, actually. So first in the
references, in the firmware, we see lots

of references to ADONIS, but that was not
enough for us. So if we actually looked

around to see if like there is any
reference to it, and well linkedin is one

good open source like reference. And he
was like one employee actually talk about

Siemens developer who talk about like
working in ADONIS. I don't know why he put

the Windows and Linux beside ADONIS, but I
can say is that like you work on this. And

so it was not enough for us. So maybe some
some of us we don't know. And we look

again further and further and we find this
thing which was the best indicator. So

Siemens developer engineer mentioned that
he worked on kernel software

development for ADONIS real time operating
system, which is a good sign for us. It

means that we are right. So now that we
know about the naming and we sure about

that. Let's look at the components. So
it's actually a start in basically

0x00040040 and basically then initializing
the kernel and then lots of routines for

initializing different components of the
operating system. I don't think Siemens

actually generalize it in this way. We
don't have such thing in the firmware,

but we actually did it like that. So we
generalize it to two groups. Some of them

are core services like ADONIS real time
operating system services, and some of

them are related to the like automation
part. So those people who are like in the

automation part, like writing ladder logic
and stuff like that, those commands and on

function codes which are relevant in
Siemens, they actually know this are like

more automated related services. So you
have PROFINET, AWP or automated web

programing MC7 JIT parser basically for
the latter logic or different kind of SD

like basically their own JIT compiler
inside the PLC. And you also have the OMS

this configuration system which is very
related again to the automation part, core

core part of the automation system and of
course alarm central all your and stuff

like that related to automation. In the
operating system part, so lots of these

usual things. So file system. So PDCFS,
which Tobias talks later about, it. The

TCP/IP stack, some C / C++ libraries,
which is not from Siemens, it's from

Dinkumware and MiniWeb Server
and MWSL Parser

or MiniWeb Scripting Language parser

and lots of different subcomponents which
is usual in operating system like any

operating system you can find. Also, there
are some references to CoreSight. I don't

know how many of you know of CoreSight or
how much you work on ARM, but the basic

CoreSight is something similar to Intel
process tracing or Intel PT for tracing

applications and can be used for getting
code-coverage, for example. And the

hardware part is very well documented by
Thomas Weber in this year, is not yet.

This year or so. This year, Black Hat
Asia, but I have to warn you, because I

received some emails, some people ask
about that. If you connect to it, the PLC

have someone to debugging feature which
detects that it's being debuged via JTAG

and overwrite the NAND-Flash with random
stuff. So you brick the PLC, so just

connected it at your own risk.
Next is let's look

at the CoreSight just quickly,
CoreSight basically have like

before I go here,
I have to mention that Ralf Philipp

also have a good talk in 0 nights about
CoreSight tracing. So I would recommend

you guys go look at that as well.
Generally, CoreSight have like 3

major parts or components: sources, links
and sinks and sinks is basically the part

which you actually get the trace
information and sources are the part which

you tell is a featuring the CPU, which you
ask what kind of sources you want to get

the data from and then links basically
convert these sources. I have to mention

that like lots, it's very useful for
Fuzzing as well too. I guess some people,

very few, but some people are working on
that things. On coverage guided fuzzing

via CoreSight, ARM CoreSight. So it's
possible similar implementation is

happened in Intel PT for example KAFL,
WinAFL or Hongfuzz. So sources, basically

they have like three different components
STM, PTM, ETM. ETM version 4 is the latest

version of it. And basically you have also
links which connects different sources to

different like different or single sources
to different or single basically sinks.

And then you have funnels for CoreSight,
sorry sinks, sorry. You have sinks, which

is basically a different kind. So there
are some integrity to the CPU which is 4

kilobytes ring buffer SRAM or you have
like system memory or even TPIU or just

for example JTAG DP Port High Speed JTAG
port. So now that cleared sink,

like the CoreSight, we actually queried S7
for existence of CoreSight and as you can

see, like in the software part is already
implemented. So they actually have some

references in their software that they are
utilizing or configuring the CoreSight in

the PLCs. And basically we can see that
the ETM version is not the latest version

it is ETM version 3. Now that I've talked
to you about CoreSight, Tobi can talk

about firmware dumps.
Tobi: So let's get to something that I'm

very much more familiar with and feel it's
easier for me to handle it is firmware

dumps or software in general, but firmware
dumps, I think it's close as you can get

to what I like when talking to a PLC or
trying to understand a PLC. So in the

Siemens case, we have a 13 megabytes
binary and at the beginning it's not as

many, but as if you twiddle around with a
bit and apply some IDA python functions

and stuff like this. You can get to like
84 000 functions, which is

not something you want to really look at
everything manually. Also, like 84 000

function firmware image doesn't really get
the sexiest firmware on planet, right? I

guess so. But this is what I what I looked
at and what we were looking a bit more in

the next couple of minutes or so. As you
can see, we have different names up there.

We have one name which is called
_some_get_some_max_size. So this is my

internal way of saying I don't really have
an idea of what's really going on in this

function, but we can also see some more
meaningful functions. So we understood

some parts a bit more. Some parts of it
less, but I gave it a cursory look in most

places. So now let's get in to a lot of
address related stuff, so we expected a

lot of details, which are very interesting
if you start looking at firmware code, and

I will explain along the way why that
might be interesting. So first of all,

what you have to know is that coretex are
for gives you bank registers. This is

basically a feature that's implemented to
lower software overhead and allow more

seamless modes, which is for the internal
CPU. And what we get is banks stacks per

execution mode. So if we want to know what
is kind of going on in the state of the

filmware at a given point we may want to
look at the different stacks of the

different modes at any given point. And
this is the addresses that we expected for

this. And you could use that if you as a
starting point, if you started reverse

engineering, things like that. Now, we
will have some address, some tables with

addresses. And the first one is RAM
mappings, which show you what kind of

functionality or what you might expect
when looking at firmware code, which is

interfacing with different parts of
memory. So if you initially go and look at

some ARM code, you may just see a random
access to some place in memory and you may

want to know what it's actually doing. And
it looks very uneventful of it's just an

address and it gets gets queued and
you don't really know what's going on. So,

for example, if you looked at an address
within the text section, you would expect

there to reside code if you wanted to see
some global static data, you would want to

look at the data or the BSS section. And
then finally, if you wanted to look at

heap memory or how channels are set up
there, you would look in the uninitialize

section and it goes on like this for
different sections. Another very

interesting thing to look at, if you tried
to reverse engineer firmware images is

that you kind of want to know what the
hardware is that a given piece of code is,

is interfacing with. And in this case we
dumped some regions or reverse engineered

what some regions are for what is called
memory mapped I/O. And the way ARM is

talking to a firmware is basically to
queue a magic value inside the address

space and then it gets something back,
which is not at all what it has been

written there before. So it's basically an
address which gets wired through to the

periphery the hardware periphery on the
same system on a chip. And here we can see

that we have different hardware
peripherals residing on it. For example,

we can talk to the Siemens PLC via
different serial protocols and those

protocols might be SPI or I²C. And we have
on the left side, kind of in the middle

top what took part of it, have some region
pertaining to that. And then if you saw

some other code talking to timers, for
example, you would know you are in timer

land at the moment or like in the
scheduler or whatever it would be.

Finally, we have

some MPU configurations which are memory
protection unit configurations, as Ali

introduced earlier. So what we can see is
that Siemens is actually applying some of

those configurations to protect parts of
memory. What we can see, for example, is

where whenever the XN so the execute never
bit is set, code is not to be executed

within this address region or we have a
read only region. We really don't want to

have it overwritten. So it's interesting
that they started playing this in

practice. Here we can see what actually
happens when the firmware itself boots up.

So it turns out the firmware doesn't
really want to depend too much on what the

bootloader did. Probably it's different
teams doing different things. And to keep

this interface as small as possible, they
kind of redo some of the stuff that the

bootloader code also does. It sets up the
vector table for handling interrupts and

similar things like that. Then if we get
past this initial stage, we actually want

to boot the ADONIS kernel which Ali talked
about before. So first of all, there is an

array of function pointers that gets
called one for like every piece of

functionality that we saw on this overview
of the different components of ADONIS. So

if you wanted to look at what kind of
components are there or functional

components are there. This is a very
interesting list of functions, function

handlers to... to examine and also sets up
some management structures and stuff like

this one a typical operating system would
have to set up. So now we look at more of

the different components of ADONIS. First
one is the file system, so PLCs is part of

the specifications. Sometimes it's how
resilient is it against temperatures, how

low of a temperature can I have this PLC
reside in without losing functionality?

And in this case, what they also want to
provide is some safety against interrupts

in power supply. So they developed a
proprietary file system which is called

"Powered Down Consistency Files System",
which they implement in the firmware. And

we can also see one of the work
experience entries of one of the previous

Siemens employees who stated that he or
she worked on this file system. We have

another part of a very critical part of
the functionality, of course, we want to

talk to the PLC, it wants to talk to us
in.. and one of the ways is fiercely

TCP/IP. And this is to expose the Web
server, for example, and different other

components. And in this case, it turns out
that Siemens doesn't implement their own,

which probably is a good idea not to do
that. They use the

InterNiche Technologies TCP/IP stack
in version 3.1.

If you are
good at Googling you can find some source

code and you can actually map this to the
firmware and how it works. So it could

give you some wrapper functions, something
like creating sockets and stuff like this

and could make it easier for you to find
those in the firmware image. We also have

one of the very critical components of
each firmware is update. If it allows an

update and the Siemens PLC allows updates,
there are different modes. One of the

modes is, just you drag and drop an UPD
file, an update file to the web server and

it will start checking firmware, integrity
and signatures and so on. And the second

way is doing it via an SD card, which has
a great total of twenty four megabytes and

it's for the low price of 250 euros. You
can can get it. I think you can not really

beat that, that ratio. If you actually
decompress this kind of UPD file, you get

another representation of it in memory.
And we did some reverse engineering on

that and we have different fields not sure
if you can see them now, but you can

expect what it is. It's different offsets
into the actual binary file. It's it's an

entry point into the firmware magic header
to make sure something is not too screwed

up and a CRC over the whole thing for
example. We also extracted some of the

addresses inside the firmware image, which
helps you find a first foothold into what

the logic is dealing with and give you
some addresses for you to refer this to

later. The next component that we want to
touch on is Miniweb, which is the web

server. It kind of exposes to you the
different internal parts of the PLC and

what the state of different GPIOs, general
purpose input outputs, is. The inputs and

the outputs and what the health of the PLC
is itself and the way that it exposes this

is using the MWSL language Miniweb
scripting language. It's as we will see on

the next over the next slide and we'll
talk to them about that in a little bit

more detail. We have a be started, has the
service as well from one of the function

handlers of the ADONIS initialization
functions that I referred to a little bit

before. So now let's get to some
undocumented http handlers, which I think

are very interesting. I think my favorites
are "lilililili" and "lololololo"..

laughter

.. and if you should put those together in
a clever way, maybe somebody is musically

gifted and can make a song out of it. I
would be very interested to hear that. So

now let's get to the MWSL the Miniweb
scripting language. So it basically

exposes the internal functionality by
allowing you to inject into an html page

by a templating different configuration
parameters and stuff like this. For

example, as we can see here on the top
right corner, you can see the CPU load of

the system at a given time. It doesn't
really seem to perform any output

encoding, so it kind of trusting what
comes out. So there may be clever ways

to... to do some web related trickery with
this and also the parsing of this

tokenization is kind of complex. I looked
into it a bit and this implementation

could also be interesting to look at, but
we will get to those kinds of

aspects a bit later. With this, we're
going to get to our actual findings and

talk about those a bit more. And this is
where Ali will take over.

Ali: Thanks, Tobi. So. So now we talk
about the capabilities which exist in the

bootloader, which allows us to have
unconstrained code execution. So basically

this feature is available in the uart. So
you need physical access to the device.

But once you have this physical access,
you can basically, as Tobias later

describes, we can actually bypass the
security ecosystem which developed by

Siemens in their product. So you need uart
access as it's documented here, you have

TX, RX and GND in the PLC and the uart
actually in previous research was

documented as well. Every address which I
am talking about here or mentioned in this

presentation are for bootloader version 4
to 1. As I mentioned earlier, Siemens

actively modified the bootloader. So I
think in two years we saw like 2, 3

modifications or different versions of
their bootloader coming up. So this

exactly is based on that's half a second
waiting for a specific command after a

second hardware configuration happens. It
applies to Siemens S7-1200 including

SiPLUS and S7-200 SMART. Actually,
somebody from Kaspersky. IS security

mentioned it. We didn't know even about
it. We just investigated a S7-1200. But

Siemens later updated that advisory that
also applies to other products as well. So

let's talk about this, a special access
feature. So as you mentioned, one of the

things the bootloader does is actually
initialize the hardware after this

hardware it's basically copy some of the
contents of the bootloader itself to a

memory segment called IRAM, basically. And
then PLC basically waits half a second for

a specific command. And once it's
received, this specific command it

responds with a specific string and it's
all happening over the uart. So it's if

you send a magic string, MFGT1, sorry for
my broken German, but probably it means

"Mit freundlichen Grüßen", I hope I did it
right. And then the PLC responds with

"-CPU" and says that now you are in this
special access mode. I am waiting for your

commands. And this address is also I
believe 0xedf8 in the bootloader. So here

is a decoding of our clients, which we
will release later next year, actually,

which you see that's 2d435055, which is
the "-CPU" response from the PLC. So now

we are in it. And also we also added some
extra saying about your packet format.

Somebody asked before. So once you send
this command, you get lots of

functionalities here in this presentation.
We call them handlers and basically they

are something we call primarily handler.
It's like 128 entries and there are some

three other separated handlers which are
like 0x80 uart configuration and bye. So

in the primary handler release, there are
lots of things. So if you go back to the 2

previous slides, I got the firmware
version here, 4.2.3. And

basically what is happening is that
basically it's this command here, get

bootloader version. We are just requesting
the special access feature to tell us

what is a bootloader version. And also you
can do lots of low level diagnostic

functionality is happening there. Also
some functionalities related to firmware

update happening there which bypasses the
usual cryptographic verification of the

firmware and doesn't need that. So let's
look at them, because for this work, which

we are talking about, we actually
primarily only use two of the handlers. So

we don't use.. we don't look at like or we
don't discuss now all others hundred

twenty eight handlers which exist in the
PLC. So it works. One of the handlers, the

interesting one for us was handler 0x80
which mentioned here, update function. So

basically what it does is that it lets you
allow you to write to a specific part of a

memory IRAM, which previously copied some
content of the bootloader. So basically

you send this handler after this
handshake, you have to do this MFGT1 and

then -CPU. And then basically you are
going to send this handler and then it

basically checks because each handler
might have different requirements. Check

number of arguments, for example, and then
you are in this update function mode. And

then you have to provide target ID because
there is 4 subfunctionality available.

Once you enter this mode and some of them
are like for IRAM, for SPI or IOC or for

Flash, and then for each of them, you have
to choose what kind of operation you want

to do you want to configure, read, write
or check. And so you can do all of these

things so you can read and write to the
IRAM. Basically, this is a function

handler at 0x80. Next is a primary handler
like 0x1c. This is listed in this handler

list, here. So, so basically it allows you
to call functions. So the basically this

functions are listed in the IRAM. And
basically what you do is that you send

this handshake, you are and you are in
this. Basically, this is what 0x1c handler

and then you can call the ID number of the
handlers which you want to use. So here

you have like lots of handler available
for 0x1c. So the question is, what we can

do with it. And before I asked Tobias I
want to ask anybody here, any idea? Trace,

somebody said trace. I don't know what
that means, but

mumbling in the audience

OK. You mean with JTAG? with the
CoreSight? No, we are not going to use

that. So let's ask Tobias what he can
do.

Tobias: Yeah. So looking at it dynamically
and seeing what it does with the memory

is, I guess, a good idea in general. If
you if like static reverse engineering

doesn't give you anything. In this case,
we looked through different or I looked

through different of those functions and
tried to see, what can I do with it? So

the base of where I started looking for
this special access feature was basically

that I saw there is too much in this code
going on. I kind of feel like I understood

what it should be doing. The bootloader
what it should be doing, but it seemed

just to be too much. And the way we can
combine those two functions is basically

to recap. Use this 0x1c handler, which
gives us control over what kind of

secondary list functions to be called,
which, as we saw before, is copied during

the the boot up process to a position in
IRAM from external read-only memory. And

this exposes this function handler table
to anything that can write to IRAM. And as

we learned before, the 0x80 handler is
able to in a limited capacity, do just

that. And here we can see what we can try
to do with this. So we use in a first

stage the 0x80 handler to write to IRAM.
We can actually inject another function

pointer together with some configuration
values that allows us to pass different

checks about argument sizes and stuff like
this. We can inject this as an entry into

this table and we can also write to this
table a payload which we can use as a

shell code. And then in a second stage we
can use this previously injected index

that we specified just as a trigger to
call our own payload. So now we have code

execution in the context of the
bootloader. So which is as privileged as

we can get at that point and we can see
what we can play around with this. And as

a little summary is that we chain all this
together and we get code execution. And

with Ali's words, with this technology,
we're going to rocket the PLC. And before

we go into what this actually allows us to
do is a little word about the stager

payload. So I wrote this this chain of
different invocations and it turns out

that this write to IRAM is somehow very
slow in the first place, but then also

error prone so the device can just error
out and I'm not quite sure what this

pertains to, but what may be interesting
to know from the Siemens engineer, but it

basically led to me having to inject a
little encoded payload, which just has a

subset of bytes which gives us an
interface to do to perform

reads and writes with an arbitrary
write primitive and then use this to

inject second stage payloads. And this is
what we want to demonstrate here.

Ali: Thanks. So now we would have our demo
4 demos, actually. So the first one is

actually just seeing a communication,
basically sending these requests and

getting a response and basically sending
this data payload. So the up is the raw

UART communication. Don't worry, it's
getting zoomed later and the down is like

our client, which actually talking with
the PLC and sending us comments. So we are

just running our UART. And here is we are
sending our command. And if you look at it

up, you see the -CPU signal came from
the PLC. And now we are sending our stager

and our stager just sends us just one
acknowledgement so we know that the stager

runs successfully. This is for firmware
version bootloader version 4.2.1,

basically. So now we are going to do
something else we are going to actually

dump the firmware from a running PLC and
compare it with the firmware downloaded

from Siemens' website. So for us, we are
going to actually unpack the firmware

downloaded from Siemens website because
it's a compressed with lzp3. So

that's what we are going to do. Oh, we are
actually setting up our SSL connection

first. So SSL port forwarding, ssh port
forwarding before and we are just checking

that the PLC is running properly. So like
this is not a broken PLC or something like

that. We wrote something. So we just make
sure that the web server is opening the

open the server, it's open, it's good. And
I also try to log in to the website, to

the Web server of the PLC. Just again,
make sure that the PLC is functional. So

also enter the password. I guess everybody
can guess it. And then so you see that we

log in eventually and in the left side you
see all the like functionalities which

loads related to the PLC. So it's a
working, running, functional PLC. And so

now you're going to decompress the
firmware downloaded from Siemens' website

after checking for export license and
stuff. So they want to make sure that

people from Iran and North Korea don't get
it. I'm from Iran, by the way. So here we

have the unpacked firmware. But because
the frame rate is very large, as Tobias

mentioned earlier, what we are going
to do is that we are just going to export

256 kilobytes of the firmware from some
part of the web server and into IDA. So

you have to set the big endianess for the
cpu. And also rebase the framwork. So as

you can see, here is no function yet, but
once we rebase it we have all the function

as well and yeah, so then we gotta just go
and export 256 kilo bytes from the

firmware so we specifically slow down the
UART because we want to make sure that we

don't do it's too fast to overflow the
buffer which we have internally in the

PLC. So. So here, for example, in this
address, 691e28 we are going to export 256

kilobytes. This is from the firmware,
Siemens firmware. Right. So we just

export it. So, yeah, so it's now called
fw-0x691E28 in the folder out. So now we

are done with this part. We are going to
dump the same address in the PLC. So from

a running PLC, I have to mention again. So
this is the top part is basically raw uart

and this is basically our client part and
we are dumping it with a cold boot style

attack. So we are basically resetting the
PLC. And before it's over, write the RAM,

we are basically dumping the contents of
the RAM. So this is the address, 0x691e28.

This is about the same address, basically.
And we are dumping 256 kilobytes. And here

we send MFGT1 basically. And then got
the /cpu and then the rest of the stager

and stuff goes. So now basically we are
sending packets and then eventually get a

recive. So basically got all the payload
like dumped in mem_dump_00691e28

basically. So this is from the RAM of the
PLC. This is not anymore from Siemens'

websites. We are just scped to our own
machine and then compare it. So now we

have the memdump and original firmware
256 kilobytes each. And then we are going

to compare them with each other. And as
you can see, should look here like you

have like hundred percent match. Meaning
that it's exactly the same firmware,

which is available on Siemens website. We
dumped it directly from the Siemens PLC

memory using this as special access
feature. So let's do another one. So this

time we all want to show that
unconstrained code execution in just a

very basic way. So we are actually just
writing a custom payload to the PLC and

get a hello or greetings from the PLC. So
basically, basically we just asked the PLC

to send us this message all the time. So
again, so we are sending our custom

payload here and say hello loop. And
basically the PLC just sending this loop

for us. So all of these things, again, are
for bootloader 4.2.1. You have to readjust

certain things because Siemens saying they
updated again their bootloader in the

recent 2019 December, which we bought new
PLC, again, once again. And now here we

get a response. That's the PLC is sending
basically to us this our raw data, which

is PLC is keep sending to us. That's
showing that we are receiving this. But

maybe this was too basic. These are the
raw data which we are getting from the

PLC. Let's actually do it a little more
complex. Show something that is not from

us. So let's play a game called tic tac
toe inside the PLC. And I guess if you

don't know, this is how tic tac toe is
like this is I am playing and I just draw

with the google. So. Now we are again are
going to send our custom payload. But this

time we are just use partial quotes from
somebody else from the Internet and just

upload, compile it and then upload it to
the PLC. Obviously, you have to readjust

lots of things. But so we are sending our
payload, including a stager and these are

the raw data. Again, these are our client.
And eventually you will see a tic tac toe

interface, which you have to enter. So
Player 1 is actually playing with the X

and player 2 is playing with like 0. So
you see of any positioning, which you

choose. You have X, X and hopefully a
player one wins. Yes. So that was it. So

that was a demo.
applause

Obviously, there are lots of other ideas
which we can work on, on injecting other

custom code, using the special access
functionality, we are still working on

this. Like lots of other things on
Siemens, we are sorry Siemens we are just

working on this, but there are more to
come. But in the meantime, there are some

ideas for other people in case they are
looking into this and one to investigate

security of Siemens PLCs. So using this as
special access entry, you can do somewhat

certain things. So, for example, you can
use this prophylaxis functionality to

write to the firmware. As we mentioned,
this functionality is available and it

doesn't require those cryptographic
signature which normally during update

process of the firmware available. So you
can just bypass it and it's just CRC

checksum. So what you can do is that, for
example, adding entry to organize like

initialization routine, which is
available. And then also you can do it

before organized initialization routine,
which we call internal th_initial

Another one which we can do,

if you remember,
Tobias talked about some undocumented and

lots of creativity on creating music.
li li li lo lo lo

So what one person can do is

like basically adding specific handler or
overwriting existing handler. And what it

makes actually is like something like
triton. I don't know if anybody know her,

but triton is malware which were
attacking petrochemical plant

in Saudi Arabia.
So they were trying

to do it in the TCP. But
attacker here can maybe do it in http

example and just listen and waiting for
comments and also other alternatives like

patching one of the jump tables in the AWP
handlers, which can be also used for

process a specific attack. So what else is
out there? So what we looked is we looked

We looked at

at attack surface in the Siemens S7 PLCs.
There are like for from prospective on

local privilege attacks. What we can...
what we looked was bootloader. We are

still working on hardware attacks and some
hardware software attacks on the edge. Is

this still ongoing work, which we don't
obviously discuss now? Also interesting

thing, I think if somebody who is
interested in security of PLCs and

especially internals, I'm not talking
about like just general segregation of

network and stuff like that in ICS, I'm
talking about more advanced low level

stuff. We think like MWSL is interesting
target. There probably are some like bugs

in their implementations. Also, with
respect to file system parsing and

firmware signing, there are probably
some stuff and also MC7 parser basically,

which they have from privilege escalation
perspective and also from remote code

execution perspective, both
MiniWeb webserver and also any network

access of accessible services which they
have might be interesting. You're actually

also looking at this part right now. So as
a conclusion. PLCs are becoming more

complex. That's true, because they are
actually providing more and more features

and because of this more complexity, there
will be more bugs. We can see, for

example, in the MWSL, which we are looking
at now, also bend or strike to basically

more make it more complex. They have
basically some anti debugging which we

just discussed in Siemens PLCs, but also
they have, for example, frame rate

integrity verification so that the sign
frame where like upload to the PLC and

stuff like that. So they are making it
more complex. But what you have to know is

that if in their like thread model which
like lots of people make or this security

ecosystem which they built. If they have a
feature which undermines the same security

ecosystem which they designed. I mean, I
think it's obvious that they have to

remove like in the case of bootloader case
in their special access features. One of

the good examples. So. And of course,
customers also have to know, because if

they have such functionality and they need
it, as long as customers know, it's fine.

But when they don't, they can't risk
calculate this risk in their strategy or

in this threat model, which they have. So.
And also they have to think or rethink

about security by obscurity. Maybe they
allow us, for example, as researchers to

access the devices
better and easier

to investigate it more. We are still doing

it, but it's just taking longer. And I
believe that there are lots of seeing more

to be done on like PLCs and Siemens will
not be the last one which we are working

on. So we have to thank some people
Thorsten Holz our supervisor, he's not

here. Thomas, Alexandre, Marina, Lucian,
Nikita and Robin. For their help and

their work. And now we are going to answer
questions.

Herald: Thank you.

applause

Herald: So, yeah, feel free to line up for
the microphones or write your questions in

the Elisa room. Ah, there you go. It's on
right now I think.

Signal Angel: Hello. Yeah. So there is one
question from the Internet. Did you check

the MC7 parser? If yes. Did you find any
hidden unknown machine instruction

on it or something?
Ail: Do you want to answer? So just is it

recorded or I have to repeat it again? So
they ask that if we check the MC7

parser. OK. So it's fine. So we didn't
like truly investigate the MC7 parser,

but we are working on it right now.

Mic: Hello? How were you able to find the

MFG security password?
Ali: That's a very long story. First of

all, like we had we had it in front of us
for a long, long time until Siemens

introduced this anti debugging feature.
And after that, like we had to find other

ways, other means to find it, to find a
similar function, like similar ways that

allow us because one thing which we didn't
discuss here is that we didn't tell you

about how we, for example, executed that
instruction before in the PLC. It was

involved some works which we received help
from some researchers in Netherlands and

in France. So this is this was something
informed by Siemens in 2013. I think they

knew about it. But until 2016, they
patched it and then it became out like

basically they tried to protect their PLCs
from these kind of attack. It was never

published before. So we were using it. And
we don't want to talk about it, because

the original author didn't want to talk
about it. But we replicated what they

were, what they were doing. And then once
we really had to look for other ways, like

then it opened our eyes that there are
some other functionalities as well. There

are so such as, for example, the
bootloader. But before we before we need

it, like we never actually looked at these
things. So it was like in front of us for

like two years.
Tobias: Maybe one interesting piece of

background story on this is that we
actually in the previous technique that we

used, we actually overrode the conditional
jump that would lead to this special

access feature being executed with an
unconditional jump. So we basically cut

out 60 percent of the whole code of the
firmware image by accident. And then I

just because of the hunch that I was
talking about before that there is just

too much functionality. I revisited it and
actually realized that it was exactly the

spot that we overrode before and we had to
basically replace it and use it for our

own sake.

Mic: Is there any boot time security other

than the CRC check? So you. Are you able
to modify the contents of the SPI flash

and get arbitrary code execution that way
as well?

Ali: So it depends in which year you are
talking about 2017, 2016. So we are

talking about the same models of the PLC,
but in 2017 and 2018. No. So you could

basically just take out SPI flash
overwrite it. And that was fine. But if

you were overwriting and it caused a halt
in the CPU core, it would again trigger

that anti debugging technology, which they
have. This watchdog basically but from

like frameware integrity verification.
Well basically once you write to.. the

firmware is written to the NAND flash, but
it's just the CRC checksum. But during the

update process? No. There are some
cryptographic checks, but once it's

written, no. There are some problems which
there which again, it's a still ongoing

work and we don't want to discuss about
it, but nice catch.

Mic: Thank you.
Mic: Hi. Thanks for the talk. Could you

elaborate on your communication with the
vendor and the timeline?

Ali: Yes. So, first of all, we know about
this problem for like one year and half

before we reported to the vendor. And the
primary reason was that we were using it

for some other project. This is actually
this result is actually from a side

project rather than the main project,
because the main project is still

something else and is still ongoing. But
from a side of that projects, we had that

access. And because we were worried that
reporting to the vendor, they can fix it

with software update and then do not allow
all other CVEs which we find from this

other project, we didn't want to
eventually at 2019. Thomas Weber wanted to

talk about his talk on like basically this
JTAG interface with four CoreSight and

then we decided to actually talk about it
as well. But other than that, we actually

talked in June I think with Siemens and
they confirmed that there is this hardware

base, a special access feature. And they
are.. they say that they are going to

remove it and that was it. We also send
them a write up for them to read.

Herald: So there is one last question from
the signal angel over there.

Signal Angel: So there's another question
from the Internet. If tools like flashrom

doesn't have support for unknown SPI
flashrom chip, then how do you usually

extract firmware if you don't want to
decap a chip or use SOIC8 socket.

Ali: Can you repeat it again? I didn't get
the question, did you?

Signal Angel: If tools like flashrom does
not have support for unknown SPI flashrom

chip, then how do you usually extract
firmware if you don't want to decap chip

and use SOIC8 socket.
Ali: So first of all, we never actually

decap the SPI flash. So that's just did it
for the CPU. And just because we want we

know that Siemens relabled their PLC, so
it's not their own CPU, it's from

Renesas, but that's why we did the
decapping. So story of decapoing setting

aside. But from other things all basically
there are still this functionality, this

bootloader functionality, which actually
lets you read the content of the memory.

So that's one thing you can read.
Obviously you don't even need that thanks

to one of my students. We now know one
that's actually you don't even need to

take out the bootloader, chip. We
basically can just connect directly in the

board and dump the firmware. Marcello,
that's his name. He's here, actually. But

anyway, so you can just directly read it.
And yeah, I don't think the reading part,

especially some part of it, is protected,
especially in the recent versions, which

you can't read everything. But besides
that, I don't think there is any harder

now yet. I am sure that they are working
on that and we are working also on

something to bypass that. So.
Herald: Okay. That was our next talk is

gonna be about delivery robots. Sasha in
20 minutes. So let's give you a hand.

applause

36c3 postrol music

Subtitles created by c3subtitles.de
in the year 2021. Join, and help us!