34C3 - SCADA - Gateway to (s)hell

prerol music

Herald: So a very warm welcome to Thomas
Roth. He is a security researcher and his

specialty is exploiting techniques and
reverse engineering and industrial

security. And the talk today will be
about out SCADA the gateway to shell.

applause

And just one little notice: this talk
will be in English and will be translated

in German as well.
Thomas Roth: Thank you.

Herald: Yes.

Thomas Roth: Awesome, thank you. OK, yeah.
Welcome to my talk gateway to shell. Who

am I? He already introduced me, but still
my name is Thomas Roth. I'm a security

researcher. I do a lot of low level
security, so a lot of ARM reverse

engineering, Coldfire and so on. And
yeah, you can find me on Twitter or if you

want to write me an email. Feel free to
send me one to [e-mail].

Before we start a short introduction to
the background of this talk, so, this year

I did some SCADA penetration tests and I
found that while the PLC sensors

are pretty well covered in the security
research area, I found that all the small

devices that surround SCADA environments
are not really well covered. So basically

we have the big Siemens PLCs and so on,
and there's a lot of research going on

about them. But there are also a ton of
other small Ethernet devices involved in

industrial networks that are not really
researched very well yet. And all devices

that we're going to talk about are running
their latest respective firmware.

Unfortunately, there will be zero days and
these are not theoretical attacks. Like if

you go to Shodan or similar search engine,
you can find tens of thousands of these

devices vulnerable and open in the
Internet. So let me give you a quick

introduction into the terminology in
SCADA, because I know in the title I say

SCADA, but actually it should be ICS,
which stands for industrial control

systems, because basically ICS describes
the whole system from your supervision,

the big room with all the big screens up
to your PLCs the sensors, the actors and

so on that you will find in your
installation. And the term SCADA just

describes the supervision and control
centers. So the big screens that you might

know from movies and so on, where when the
bad guy comes, suddenly all the lights

turn red. Then there's something called a
PLC, which is programable logic

controller. It's basically like an
Arduino, just for industrial applications

and they are really easy to program and
you can get them from Siemens or Schneider

and so on and so forth. Then there is
something called an RTU, a remote terminal

unit, which is a small device that
generally are, well, back in the day, was

only used for monitoring. But today you
can actually program a lot of RTUs. So

it's kind of a mix between a PLC and an
RTU. So it's basically a PLC in a remote

location. Alrighty, to the actual topic,
industrial control gateways. So when you

look at industrial control network, you'll
find that there are a lot of different

sensors and actors and a lot of them speak
different protocols. So, for example, some

might be serial, some might be IP, some
might be Modbus and so on. And so you can

buy these small gateways that connect all
these different protocols to an IP

network. So, for example, via Ethernet or
even via GPRS or Wi-Fi and so on. And I've

seen them in almost any industrial
installation that I've seen. So, for

example, they're used in power plants.
They are used in water dam control

systems. They are used to control the
power grid and so on. And the security

concept is, "Hey, but these devices are
airgapped!", so it doesn't matter really

if they are vulnerable or not fully up to
date and so on, but that's not really true

because a lot of these devices, while they
might be airgapped, they also have

antennas and they are interconnected by a
ton of different wireless protocols such

as Wi-Fi, LoRa or GSM or even proprietary
radio links. So, yeah, and even the

case studies show that basically in this
case, you would have a monitoring network

that's connected via the cellular network
to control the water mains and so on and

check the pressure. Or even worse, they
even recommend that you connect the actors

like valves and water level gotchas and so
on over GPS, which we know is not a secure

protocol to do anything that could
be critical. Or you have stuff like

water storage tanks that are controlled
via Wi-Fi and so on or even public in the

Internet. So, yeah, these devices are
airgapped? Nope. So attacking in the field

I already mentioned, if you go to
Shodan, you will find a ton of different

devices reachable via the Internet
and even via GPS. So if you live

close to, for example, a dam or something,
it's kind of interesting to look at an SDR

or similar radio equipment to see what's
going over the airwaves, because you will

find a ton of interesting stuff and
sometimes, you can even very trivially get

a physical access to the in field devices
because they might just be in a white box

somewhere hidden. And if you break into
it, you can pull out the SIM card and it

will put you directly into the SCADA
network, if you're lucky. Don't do that,

by the way.

laughter

So, yeah, let's let's hack some gateways.
So the equipment you will need to and

everything in this talk was done on this
desk, just using these devices here, you

really just need a laptop, you need an
oscilloscope or similar measurement

equipment just to ensure that you don't
burn out your logic analyzer. You need a

logic analyzer, a soldering iron, a
multimeter and a power supply. And that's

really basically it, because you can hack
almost any embedded device that's using

these devices and to find potential
targets. I have this kind of map where

first try to understand, can I get the
firmware of the device or do I have to

somehow, for example, use J-Tech to get it
out of the device? Can I actually buy the

devices at a sensible price? Because some
of these devices cost like 600 € or so,

and if you buy ten of them, that gets
expensive very quickly. And so, uh, I need

to check eBay and see what devices can I
actually buy. And they should be half what

current, because if you look at all the
devices, like 10 years old or so, they are

completely broken. You don't even have to
look to start to look at their security.

So, yeah, the first device that I that I
choose to really look at was the moxa

W2150A, which is this small device, which
is also mounted on the board right here,

mainly because I found the phone
was available and it looked like an

interesting device because it has Wi-Fi
and so if I managed to break into it, I

can jump an airgap potentially. And the
W2150A is just a simple device server. So

you can connect any serial device, any
RS485 device simply to it and it will be

exposed via Ethernet or even via Wi-Fi.
And you can download the firmware publicly

and it's available on eBay relatively
cheap. So like 150 bucks or something. So

I downloaded the firmware and I
looked at the entropy of the firmware and

I immediately saw that the entropy is very
high, which means either it's very

compressed or it's encrypted,
unfortunately, using a tool called

binwalk, which is really useful for
looking into firmwares I saw that there's

no compression detected. And so it was
very likely that this firmware image is

encrypted. But I noticed on the Web page
that before you upgrade to version 2.0 or

2.1 of the firmware, you must upgrade to
the firmware version 1.11. And I thought,

that's interesting. Let's look at the
release notes for version 1.11. And it

turns out that 1.11 adds the support for
the encrypted firmware. So I downloaded

the one point eleven firmware and sure
enough, it's unencrypted. And if you've

ever done anything with ARM before, if you
just look into a firmware hex dump, you

can immediately recognize whether it's ARM
or not, because the first four bits of each

instructions are the conditional bits
and those are almost always E. So if

you see a Hexdump and roughly every fourth
byte is an E, you know, this is an ARM

firmware and it's not encrypted or
anything else. And so, yeah, sure enough,

I ran binwalk on this image. This time we
see there is a huge drop in entropy, which

is the bootloader and so on, and then a
high entropy, which is basically the all

the compressed filesystems and so on. And
binwalk was able to detect the SquashFS

filesystem and extract it for me very,
very easy. And so my goal was to extract

the firmware, find the firmware upgrade
code and somehow try to decipher the new

firmware. And so I was browsing through
the files and sure enough, found the file

that was helpfully called
libupgradeFirmware.so and if we look into

the symbols, which they luckily didn't
remove or anything, there is a beautiful

symbol called firmware decrypt.

laughter

So we load the whole thing into
disassembler and we see that

there's some fancy XORing going
on in the bottom left corner. And I'm

going to walk you through what's, what
exactly is happening in this code.

So basically, first, there's a variable
called password loaded into the registar

R2 and then a second count variable is
basically set and it starts looping and

increasing always by four and goes through
this whole xor shebang and it turns out

that this is the obfuscation method for
the AES Key. So, in password, in memory,

we have an obfuscated key and we can be
obfusciated by just implementing the code

we see here in C or in the emulator.
And sure enough, eventually this

will be used as the key into the ECB 128
AES decryption. And so I implemented the

whole thing in C, it was almost a copy
paste from the decompiler, so you can in

IAD Pro, you just hit F5, copy the C code
at the bit, fix the memory offsets and so

on. And you have the whole key obfuscation
method basically reverse engineered almost

automatically. And so I compile it. And
sure enough, Moxa key extration, it turns

out that the key is two eight eight seven
Conn seven five six four. I build a short

script to decrypt the 2.1 firmware and
this time Binwalk finds all the files and

we can start reverse engineering the
actual firmware.

applause

The scripts for this are available on my
github. I'll push the actual decrypts stuff

after the talk because this is the first
time this has been released. And so after

I was at this point, I knew that the
firmware is.. I can decrypted the firmware

I can look into it. By the way, it's not
signed or anything. The only verification

method is CRC32. And so at this point I
knew, OK, I can buy this device and

start playing with it. And so I went to
eBay, I bought one. I got it. I screwed it

open. And sure enough, there's an ARM
processor in there. It's an Freescale

i.MX25, which is just a regular ARM
processor. It's like 400 MHz or something,

I don't know. And I started probing all
the all the small pins inside of the

device to try to find JTAG or serial
or anything. And so I actually hooked up

my power supply to foot pedal so that I
can probe and just press with my foot to

reset the device. And sure enough, I found
that there's a full serial console

available inside of the device on these
pins. And if you boot the device, it even

tells you, please press enter to activate
this console, and so you do that and you

are root on the device.

applause

So that's kind of cool, but that means
that you require physical access, so

that's not really a vulnerability, but
it's very nice to have when doing security

research because it means you can suddenly
debug all the code on there. And so if you

write an exploit, you can just touch GDB
to the binary and start very, very simply,

writing the exploit. So at this point,
I was trying to look at the available

services on the device. So for example,
there is a web interface, there's a

proprietary configuration protocol,
there's telnet, there's snmp, there is a

serial driver protocol and so on. And I
started looking at the web interface and

there was cross site scripting that was
Cross site request forgery, there was

insecure authentication where they
basically hash on the client. So they have

some JavaScript that hashes your password
and then locks you in. Then there's a

command injection which lets you execute
code as root, there are stack overflows.

And just a week ago there was a zero day
released for the web server. So yeah, demo

time. So just let me open up the Moxa
Pitch right here. And so this one is

authenticated, so I'll just enter the
default password, which, by the way, in

the field will 90 percent of the time
these devices will be configured with

default credentials. But still, so, if we
just start browsing through this thing and

go to the basic settings, we can start
with a simple cross site scripting just in

the device name. One sec, so just for
example we just paste in some JavaScript.

Submit the whole thing, and hello 34c3.

applause

I know what you're thinking, like cross
site scripting, come on, that's not a

vulnerability, that's just nothing. So
let's look at the ping test that's

integrated into this device. And funilly,
a different device from Moxa that runs an

entirely different firmware had the same
vulnerability in the past. But if I just

paste in my ping, so my IP address, a
semicolon and then, for example, I cut

/etc/passwd and activate enter.
Here we go.

applause

Kind of funny, but, yes, for sure not
intended. All righty, but I know what

you're thinking, right, these are
authenticated bugs in the web interface,

so we need something unauthenticated. We
want something that's like cool and a real

exploit. Right? And so I decided to look
at the.. this custom TCP protocol, which

runs on Port 4900. And my goal was to
reverse engineer the whole protocol and

build a fuzzer for it, to find
vulnerabilities, that turned out not to be

necessary. So during some testing, I just
sent a lot of bytes onto this thing and

enabled crash debugging via the serial
console. And sure enough, it crashed and

put my program countdown right to
0x41414140. Wonderful. Thank you, Moxa.

applause

So, Demo time. So let's increase the size
of this a bit. So I built a small script.

Just called moxa_pown and I'll just supply
the IP address to it. Let's see. Opening a

second shell to connect to it via netcat.
Here we go, we have a root shell on the

device.

applause

So, yeah, that was the Moxa w21508,
basically rolls of the tongue. And so the

next device I decided to look at was the
Advantech EKI-1522 which you can find

right here. And it's, again, just a simple
serial device server this time without

Wi-Fi, even though they are available with
Wi-Fi. It comes with two Ethernet ports

two serial ports and so on. And I
basically followed the same steps again.

So I looked at the.. I downloaded the
firmware. I looked at the edit using

binwalk. And this time we see almost no
entropy. So there is.. this guy is

basically completely unencrypted. And
again, we saw some ARM 32 bit it runs a

Linux kernel, 2.6.31 and a BOA Web server
where the last update was in 2005. And the

firmware, I think, is from 2017. So these
are kind of outdated. And I found

during the initial analysis just of the
firmware that the main binary to look at

will be this edgserver binary. And so I
loaded it into IDA pro and looked at the

different things that calls. And there
are a lot of calls to functions like

string copy, to system, to sprintf and so
on that are generally kind of considered

unsecure. And sure enough, I am doing
static analysis. I found that there's some

code for sending an email as an alert, for
example, when the system reboots. And

the full command invocation is mailx -s
blah blah blah, and we have control over

some parts in the string because we can
configure the two address in the UI. And if

we look at what's happening
here, it basically just sets up this

format string. Then it goes to include the
subject and then it gets some arguments

from the stack and basically calls
into system. And so there's no filtering

going on at all. So we have an unfiltered
part of the system, invocation, code

execution. And this was before I had the
device in my hand. And this is kind of a

funny story because I first bought because
it was just 40 bucks, I bought this

device, which in the firmware has the same
bug, but the mail functionality is broken,

so I couldn't test it. So I had to go to
eBay again, buy another one and buy the

bigger one. And so I ordered the bigger
one on eBay. Looks like this. It comes

with a Cavium CNS C.P.U. It has JTAG
exposed on the bottom there and serial

console is available again without any
authentication. So beautiful. You just

connect your bus pirate or your UART
adapter to it and you have full serial

console. So, again, we had to look at
finding vulnerabilities for this device

and there, again, a ton of different
services, there's like a Web interface

available. There is a proprietary
configuration protocol that's based on

UDP. There is Telnet, there's snmp,
there's a serial driver protocol and so

on. And again, looked at the website and
again, cross site scripting cross side

request forgery, command injection, broken
authentication, which basically if you log

in from one computer, it uses, I think
http digest authentication, you can

connect from a completely different
computer and it doesn't ask for a

password. I don't know why that is, but..
Yeah. So I was thinking I was doing

something wrong, but it turned out it was
just broken.

laughter

So, yeah, and there's, again, a stack
overflow in another protocol. So I guess,

again, demo time. Let's first look at
the device itself, so, you know the

password, firstly, we have a nice device
description here. This is just a basic web

interface. Right. And we can, again, just
copy in some basic JavaScript

hit the save button. Reload and there we
go, cross site scripting yet again, OK,

again, not really interesting. Right. So,
um, let's look at the stack overflow.

Again, I have a small script advantech_pown.
For the IP there. And we have netcat

running on there. Sure enough, there we
go, that's root on the Advantech device

again, via stack overflow.

applause

Yeah, so two of three devices have
basically broken already. Let's look

at the next one. This one is a Lantronix
EDS2100. And this one is kind of

interesting because it's not ARM. I
normally I almost exclusively do ARMs. So

this one was kind of interesting. And this
device, which is mounted somewhere right

here. Yeah. This device comes with a
serial to ethernet secure device server.

It has two serial ports. It has
Ethernet and you can buy it in two

variants. One comes with Linux and one is
Evolution OS, which is I guess, a

proprietary operating system from
Lantronics. And I'm using the EvolutionOS

variant in this talk. Looking at the
firmware it turns out it's unencrypted and

it's coldfire architecture, which I've
never done really anything with before,

and there are no obvious external software
components. So if you go through this,

through the firmware, you'll find there's
an SSH implementation, there's an SSL

implementation, but it's not openSSL and
it's not anything very well known. And the

same is true for the web server and so on.
It's not really anything that's well

known. And this time, while probing
the device, I did not really find anything

interesting in terms of serial consoles or
so, but it just found a potential debugger

port, but it didn't have a fitting
debugger unfortunately. The CPU is from

NXP runs at 160MHz or something. Yeah.
This time we actually have a web

interface, we have Telnet SSL and it even
has a file system, so you have like FTP

and TFTP which allows you to download the
configuration, upload the configuration

and so on. And it's kind of hard to secure
it correctly because there are so many

protocols and it's not really clear what's
set up by default. But yeah, you get

the idea. And this time the web interface
was surprisingly secure. So there was no

cross site scripting. There was no command
injection, because there's also not really

a shell that you could execute commands
into. But I still found some stuff.

One is the configuration injection, which
allows you basically to change the format

of the configuration using a different
field. And I found an authentication

bypass, so I was able to write a small
piece of code that takes a while and then

completely removes the password from the
device. Demo time. So if we connect to the

Lantronics device, it will currently ask
for a password, which in theory we don't

have. Let's clean up here a bit. I know
it's just. And let's run Lantronix_pown,

oh, that was fast. That worked. Yeah, sure
enough, the password is gone.

applause

Awesome. To be honest, I didn't expect the
demos to go so smoothly, so I put in an

hour for the talk for this went very well
so far, so that's good. So before we

finish already, some other devices are
even worse. So, for example, as I

mentioned, I bought some other devices,
for example, this Advantaech device and

this Moxa device and this Lantronix
device, which are basically the

predecessors of the other devices. And
those guys are really interesting to look

at, one could say. So, some of those are
running eCos, which is an embedded Linux

platform, which was last released in 2009,
and some devices run a Linux kernel with

the 2.4 version and you see Linux without
any memory protection whatsoever. So even

if they, so even a small stack overflow in
one of the userspace applications gives

you full root access to the device because
you can directly exploit the kernel and

there are unfixed public vulnerabilities.
So in the first penetration test that I

did, that included actually this device
and Moxa and part of a small one. I found

that using SNMPWwalk, it gives you back
the administration password via SNMP.

laughing

And so I went online. I tried to report
it. And it turns out it's well known

there's a metasploit module for this

laughing

and it's unfixed, OK? And these devices
are still in support. So I don't know why

the vendor is not patching this. Yeah. So
the summary with trivial vulnerabilities

in most devices, or at least all that I've
looked at, there are no security

mitigations whatsoever. So they don't even
enable like the compiler flags that you

just set and then you have at least some
kind of stack protection and some like

stack cookies and whatnot. And some
vendors are really bad at responding to

vulnerability reports. So, yeah, I'm not
going to name the vendor, but not even, on

Twitter I asked them to please give me a
security contact and they responded,

please use our contact form. I said I did,
three times. I send you emails, you're not

responding to me. And so they stopped
responding to me on Twitter too.

laughing
applause

So how to mitigate? Well, the only way
that I would see to mitigate against this,

and I'm more on the deconstructive side of
the story, is defense in depth. So never

directly expose any of these devices to
the Internet, even if they say they

support VPN, even if they say they are a
secure device of whatever, just don't do

it. Get a real VPN gateway and make sure
that you never rely on a single level of,

for example, encryption. So, for example,
WPA2 was broken by the crack attack and

they actually released a patch for it
after two months. And these are these are

still two months where you are exposed to
vulnerability on your potentially mission-

critical system. Also never use GPRS for
these devices without VPN because it just,

it will go wrong. Okay. Yeah, thank you. I
guess now we have time for Q&A. Thank you

all for coming.

applause

Herald: Thank you very much for the talk.
So we have very much time for Q&A. So

please line up to the microphones and we
have someone at microphone 4 already.

Mic 4: Yes, hello. Hello. Thanks for your
talk. This is.. obviously this is a

problem. This is a part of the bigger
problem of security in IT. Right. In

anything related to any kind of
technology. And this is only going to go

worse with time, right. Internet of shit,
internet of things and so and so on, so

forth. So my question is, you gave some
ideas how to mitigate this in this very

specific area that use VPN, et cetera, et
cetera. But my question is, so hacker

community is not very, let's say,
interested in regulation. Right? And when

we see, when we see a government trying to
do something with technology that usually

goes bad, we have this idea in our head
that, OK, this can only go like this can

only go bad. Right. But so my question is:
do you think that perhaps there is some

space for regulation here?
T: There's definitely space for

regulation, but I think regulation does
not solve the underlying technical issues.

So these devices, it's 2017 and these
devices are using C-code. I think that's

just asking for trouble, basically. And so
we really need to see this shift, even in

the embedded world, to switch to memory
safe languages, for example Rust or

something similar, and really to stop
using C in this kind of context. I don't

think there's anyone who can .. Thank you.
applause

T: But there's definitely space for
regulation.

Herald: Since there was a question from
the Internet.

Signal Angel: OK, yeah, the Internet wants
to know why you are not naming the bad

vendor, because it looks like it's the
only option basically if they don't

respond to you. Let's say I asked them on
Twitter and my Twitter is right there. And

if you click on Tweets and Replies..
laughter

Signal Angel: Yeah, somebody just posted
the link on IRC.

laughter
T: I did not name them, just for the

record.
laughter

applause
Herald: So we have a question from

microphone number 2.
Mic 2: So you shown an exploit for the

last device that disabled authentication.
What did you use to achieve that?

T: So this one is unpatched and not yet
fixed, so I would rather not disclose the

details yet.
Mic 2: OK.

Herald: Microphone number 1, please.
Mic 1: I wonder if you've also been

looking at a building automation system,
control systems, or just industrial

automation control systems?
T: So you can use these devices basically

wherever you want. And I think some of the
Moxa ones are used in home automation. But

I've looked at I guess Crestron, it's
called? But not in a lot of detail. So I'm

more on the industrial side at the moment.
Mic 1: Thanks.

Herald: Microphone number 3.
Mic 3: Any field experience or even just

opinions on using industrial strength
Raspberry Pi hardware with community

supported Linux distributions or something
like OpenBC whatever on them.

T: Yeah. So I guess the big trouble there
is support, right? There are some, some

German companies and so on that provide
support for industrial Raspberry Pis and

even like nice casing and so on. But I'm
not sure if really Raspberry Pi is the way

to go here. I think there are
boards that are.. the problem is not the

underlying stack, right? It's not the
hardware. Really, that's the issue. It's

the software. And you will have the same
issues on on the Raspberry Pi. So, yeah, I

guess you could buy these devices, which
are like industrial grade shockproof and

whatnot, and put some Linux on it and
do it better. But I don't think that

the hardware or platform will
change anything at the moment.

Herald: There is another question from
microphone number 4.

Mic 4: Hi, more a social question, did you
get in contact with any development team,

software development team in any of these
companies, or might it be that there is no

one behind the emails and everything?
T: So I guess some of these companies are

really so big, that they don't reply to
you if you don't have a support contract

with them. But, for example, the support
of the ones that are not on my Twitter is

kind of decent when it comes to two
security reports. And so my next steps

will be to go via the ICS Cert, but, you
know, to report them. So, yes, there are

development teams that will get in contact
with you, just not from all vendors.

Herald: Thank you. We have another
question from the Internet.

Signal Angel: Hello? OK. The Internet
wants to know what to do about, because

there are a lot of old devices in the
field, how do you propose a vendor should

deal with legacy devices and updates?
T: Yeah, so keeping legacy devices

supported is very expensive because, for
example, if you buy a Qualcomm chip, they

will eventually drop support for the Linux
kernel for it and so on. But if you buy

like a Freescale automotive chip, they
guarantee you a certain time of support.

But then you actually have to invest the
money to regularly provide the updates and

ensure that your devices are secure. The
problem is that the lifetime of industrial

installations currently is much larger
than the lifetime of this processors' supports

and so on. So I guess we'll have to get
used to upgrading our hardware regularly

or switch to, or figure out a different
way of deploying secure software onto

them. But I really think the underlying
problem is, that we are still using

memory unsafe languages. And I guess the
fact that there's cross site scripting

just shows that there's no security
awareness really at those vendors

whatsoever. At some of the vendors.
Herald: So, microphone number 2, please.

Mic 2: I was wondering, you mentioned that
some of these facilities use GPRS.

T: Yeah.
Mic 2: Do you know if they have mostly

their own closed infrastructure, or if
they're using general consumer telecom

stuff?
T: So they will use commercial

networks mostly, and then they have custom
EPNs which have an IPSec tunnel or

something similar to their premises. But
there's also there's also a company that

sells industrial control SIM cards
which give you a public IP and you don't

want to search on Shodan for that vendor.
Mic 2: Yeah. Thank you.

Herald: There is a question from
microphone number 3.

Mic 3: Hi there, isn't economics meant to
solve some of these problems? We're not

talking about dirt cheap devices. How
surely at 300 bucks you should better have

someone who's read security one and one.
How long before a large organization gets

the result of their security audit and
goes to the aforementioned vendors and

says, provide us something that's not
trivially hackable, otherwise we stop

buying your rubbish?
T: Well, I mean, it's the same in all of

IT, right? So everything has
vulnerabilities. And yes, there should be

market pressure. But that's why I'm trying
to raise awareness for the issues that

these devices have.
Mic 3: Thanks.

Herald: There's another question from the
Internet.

Signal Angel: Yep. The Internet wants to
know how and if it's a good idea to raise

the level of awareness in public, because
they think it's a good approach to make

people, the public know that, well,
infrastructure in the cities is at risk.

T: Uh, sorry. Could you repeat the first
part of the question?

Signal Angel: Yeah. They want to know how
to raise awareness for this in the public?

T: Good question. I guess we need some
news articles or something about this in

regular paper, but I personally think it's
just an accident waiting to happen. So

eventually someone will turn off the
lights in a city or wherever, will open a

flood valve or something. And that's when
the awareness will start.

Herald: There's another question from
microphone number 4.

Mic 4: OK, for what kind of industrial
processes are these devices you just

demoed used?
T: So I've seen them in power utility. I

know they're used in water dam
control systems. They are used and in

serial connecting a CNC machine to the
network, they are used in connecting all

kinds of stuff. Because if you have a big
plant, you have a ton of different

sensors. So you might, you might need the
water level sensor. And for whatever

reason, you only can get it with a modbus
and then you need to convert the modbus to

TCP and then you need one of these
gateways. And so, I've seen in one

cabinet, 20 of them. So they're
really used a lot I guess.

Mic 4: OK, thank you. I just retweeted
your tweet to Star Alliance.

T: Huh. laughs Thank you. laughs
Herald: So there's another question from

the Internet.
Signal Angel: Yeah, the Internet wants to

know if you did any research on MQTT
for example from like Beckhoff uses?

T: I actually talked to someone who
recommended me to look at Beckhoff

yesterday, but I've not looked at them
whatsoever yet.

Herald: And there's another question from
microphone 3.

Mic 3: OK, could you show the Moxa web
panel, because I would like to double

check, which proves that they and they
would like you to see their Web page. And

I think this browser isn't very secure.
T: OK, let's take a look.

Mic 3: Yeah, and under gohead the
webserver small print.

laughter
Herald: Nice finding.

T: That's probably the issue here.
laughs

Herald: Are there any more questions? Any
questions from the Internet?

Signal Angel: The internet wants to know
how a memory safe language would prevent

the authentication bypasses you showed?
T: Not one would not be protected against

but it protects against a ton of other
stuff. It's just one example of where the

industry needs to change. We need to stop
using memory unsafe languages. We need to

start really thinking about security
design from the start, and we must not in

2017, there's no excuse for having cross
site scripting or anything on the web

page. That's also if we in the
Lantronics website, if you click logout,

it tells you logout is not supported in
your browser.

laughter
T: Probably because I'm not using Internet

Explorer five.
Herald: So there's another question from

microphone number 3.
Mic 3: Any remote part of the exploit

where you did a buffer
overflow - I think.

T: Yeah?
Mic 3: What I'm wondering is, are

there.. isn't it like very standard to
have ALSR on these devices?

T: No! laughts It should be, but it
isn't.

Mic 3: Okay. Thank you though. That was
pretty much my question.

Herald: Is there another question from the
Internet? It doesn't seem like it?

Signal Angel: So, one just came in, OK, if
you want to hear it. Ok, nope.

laughter
Herald: So, all right, give a very warm

applause to Thomas Roth again!

applause

postroll music

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