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!