so please give attention please to
Jungle ferency
hey everyone
my name is jungle ferenzi and I'm an ID
security specialist at ukatami
and in this presentation I'm going to
tell you a story about how we found a
critical vulnerability in an industrial
firewall
why do we need industrial firewalls well
a lot of industrial appliances are
simply not made to be secure and thus
they need protection
however regular firewalls are not always
suitable for this kind of job since
industrial environments suppose uh
special special requirements such as
white temperature and humidity ranges or
special protocols that needs to be
analyzed and so on
in one of our projects at Academy we are
working on creating a secure industrial
firewall with policies and the
University of Saget
and in order to make something better
first we have to evaluate the security
measures of a few existing devices
and during this assessment we are trying
to find vulnerabilities and our goal is
to eventually gain root access on the
device dump the file system and analyze
the results
so how are we trying to do this well we
usually divide the penetration
penetration test into two sections a
hardware and the software based tests
um during the hardware the pen test we
try to gather information about the
device then open it and analyze how it
works we usually look for connectors and
test points which can give us low level
access to the operation system and if it
is necessary we can also desolder the
flash and then they or extract the
firmware from it
after we are finished with the hardware
side we focus on the software components
and
we usually map the interfaces and the
services and we can then perform a black
or gray box analysis and if we have
binaries we can also do static or
dynamic analysis on them
so the subject device it was made in
2010 and why it can seem that it was a
long time ago industrial devices have
longer lifespan than regular ones so it
is still not absolute
the device can perform protocol analysis
and packet filtering and it has a
configurator application which can be
used to configure the device via USB or
wired Network
the device is allowed to the mines
meaning that it has a MAC address but it
does not have an IP address and in this
contact context it appears to be
transparent to the rest of the network
so it's easily Deployable
all right so let's start off with the
hardware side
well let's take a look at the outside as
you can see there are two ethernet
connectors on the front
a stereo connector a USB port
uh redundant power plug some feedback in
this and another additional port
if we take the device apart we can see
that there are three pcbs inside two
holding the ethernet connector itself
and one for the main board
the main board has several shifts
installed including a system on the chip
two RAM chips a flash chip
to ethernet transceivers a Serial
transceiver and fpga
the fpga is is kind of weird to see
because it's usually a costly component
but in this case in this case they use
it to physically disconnect the USB port
from the CPU
so can you see anything interesting on
the pictures
if you sit close enough perhaps you can
there is a connector on the bottom of
the board next to the CPU
this is this kind of connectors are
usually used for programming the board
via JTAG or they can provide provide low
level debugging or sometimes even shell
access via uart
while we managed to figure out the JTAG
pin out we unfortunately did not have a
device which could communicate with this
chipset
and we did not find the uart or other
protocol on these pins and since we had
the had to keep the device operational
disordering The Flash chip was not an
option so we had to conclude the harder
side of the pen test at this point
so let's take a look at the software
side as I mentioned before there is a
USB port on the front of the device this
USB port can be used to fetch some
diagnostic data from the device most of
the data is encrypted however there are
a few plain text files containing
information such as the firmware version
or network statistics and so on
the USB port can also be used to deploy
a configuration by generating one using
the configurator however the
configuration file is encrypted so it is
not really useful for us
on the other hand if we configure the
device via the network we can create a
packet capture
and we can see what's going on during
the configuration
as it turns out the configurator uses
portnacking meaning that it sends a
magic packet containing a payload or in
this case an encrypted payload to the
device which in response opens a port
for the sender and then a secure share
communication gets established
but if they use SSH could it be that the
configurator is executing just plain old
share commands maybe maybe not
basically at this point we have two
options the first one is to break the
port knocking somehow get a hold of the
SSH private key and log in to the device
or we can also modify the config the
command that the configurator executes
via the SSH
to achieve any of these we first have to
analyze how the configurator works
there are two analyzation methods static
and dynamic during static analysis we
try to figure out how the program works
without running it for example by
disassembling or decompiling it and then
looking at the instructions why during
Dynamic analysis We Run The executable
and analyze the contents of the memory
or we debug it and so on
the binary itself is 65 megabytes which
is large but not undoable but
unfortunately Ida was unable to process
it
and we dig into the configurator's files
looking for some clues why item may have
got stuck and we found a bunch of jar
and other Java related files we also
found tool called jet VM which as it
turns out is a Java to native code
compiler and an obfuscater
and unfortunately there is no the
obfuscater available for this tool so we
had to move the dynamic analysis
so
during the dynamic analysis we started
by creating a memory dump from the
configurator while fetching the
diagnostics from the device
after this we analyzed the dump with
Beam work strings and other analysis
analysis tools
we found an interesting text called node
Diagnostics containing a lot more
information than the one we fetched via
the USB port
it reveals the firewall rules
the routing table
details about the connections
the script itself that creates the
firewall rules
uh list of the installed packages and
the corresponding versions
log messages with more details than the
one available in the configurator itself
a private key which got us excited but
unfortunately it is encrypted and we
were unsuccessful decrypting it
and we also found as in an interesting
past pointing to a share script called
node Diagnostics
could this be that this node Diagnostics
share script is responsible for creating
the text we are seeing
well if we look further we find a list
of running processes which includes an
entry where the node Diagnostics path is
passed to sh which executes it in a new
shell and as you can see this new shell
is running as root
so
let's search for this node Diagnostics
path in the memory
and if we stop the execution at the
right moment we can find it in plain
text as you can see
we can also find it in another location
saying exit executing command and the
path itself
so
we change the path
to test test which is an easily
recognizable and searchable pattern and
after executing after fetching the
Diagnostics sure enough we found the
string saying executing command test
test
and not just that but we also found the
different strings saying sh test tested
Nest Mount meaning that the device tried
to run test test as root
so
at this point we have arbitrary code
execution we can modify the node
Diagnostics path and run anything we
want basically there are a few
limitations such as that only the
standard error gets locked the length of
the command itself is limited and the
return length is also limited however we
can deploy longer scripts via the USB
port and if we need we can pipe the
results into head or tail to get
different segments of the output
so that's what we did we inserted the
pen drive and dumped the file system to
achieve this first we had to figure out
how the fpga isolated the USB port from
the CPU because nothing was showing on
in LS USB however after finding the
relevant script and undoing the metric
we were we had no more obstacles ahead
of us
what we found are scripts configuration
files custom binaries public and private
Keys including the config encryption
query although it is important to
mention that the configuration
encryption key is unique for every
configuration
and of course we also found a lot of
answers to our questions and useful
insights for the projects
so
what are the key takeaways what did we
learn well
first of all security by obscurity is
once again not the solution to protect
um resources they thought that the
device is secure and we managed to
exploit it and remember that this device
could be the barrier the last barrier
between critical infrastructure and an
attacker
secondly it is also a good example why
is it so important to penetration test
your assess with experts no matter
whether it is a hardware device or a
software solution
and finally this is a friendly reminder
to fix your mistakes because we notify
the manufacturer over a year ago and
still got no answer from them
yes one can say that this is an
architectural issue that's hard to fix
and exploiting it requires Insider
knowledge but it is still a
vulnerability and it needs to be fixed
so I thank you so much for your
attention and if if you have questions I
can answer them now and if I have as I
can see I have a few minutes left I can
show you a demonstration about the
attack in
in work
thank you jungle uh before the
demonstration does anybody have any
question uh related to
this presentation just now
okay if you do have anything uh chongo
will be available uh around lunchtime or
this afternoon so jungle please continue
with your demo thank you all right so
what we are going to see is the output
of the uh the screen of the
x64 debugger I'm going to attach to the
configurator application
and search for node diagnostics for the
no dialogues string in the memory
and after I found it
I am going to modify it
and the command I'm going to inject is
LS so it is going to list the contents
of the root folder itself
so after the modification I go back to
the configurator and fetch the
Diagnostics to execute the command I
have just modified
and
after it finished I go back to the
debugger I searched for I search for the
node Diagnostics uh sorry the exit
status string which is always located
before the result and if I modify the
contents to list it in a more readable
format you can see the contents of the
root folder
thank you
foreign
's very first Public Presentation
um does anybody have anything to
question or to add
okay oh yes we do
you said the the firmware the device was
released in 2010 how many firmware
releases has been since 2010
approximately if you know
um I cannot give you an exact number but
um I believe there are a few years have
passed since they last released an
update for this device
oh
anybody with anything else
no in which case
again changa thank you and
congratulations
thanks