*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 thomas@stacksmashing.net.
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!