 we have our next talk that is about to start. It will be given by Vladimir Deschenko. Unfortunately his partner Sergei cannot be here so he's going to be handling this one solo and it's going to be on Pawning, the industrial IOT, RCEs and back doors are around. Alright thank you. Hello everyone, thank you for joining our session with Sergei. He's supposed to be standing right here next to me but unfortunately he cannot come here due to like a super long process of getting visa to United States. But anyway, Sergei, hi. And yeah, today me and Sergei we're going to talk about the different vulnerabilities that we have identified for the last I guess 15 month in different industrial devices. But we will be focusing on the industrial internet of things. So I will give a brief explanation what is the industrial internet of things, what we have identified. But first I would like to mention that me and Sergei we are working at the non-profit project in Casper scale up. It's called Casper scale up ICSR. And basically what we do, we do different vulnerability research. We do different sophisticated malware analysis. We're tracking different sophisticated attacks on the industrial components and stuff like that. So we are a group of people who has like different and super cool background in malware analysis, penetration testing, security audits, security analysis and blah, blah, blah. Alright. So what is the industrial internet of things? So you guys probably know that there are like normal, general internet of things like right behind you, right? So this is a new type of the concept, like general internet of things. New type of the concept when different vendors are trying to make any products smart. Smart this, smart that. Everything is smart. People are smart. Things are smart. But industrial world is also trying to go towards that way. So you probably can hear about or heard about the different smart meters, smart devices and stuff like that. It helps to industrial companies to lower the expenses on different things. For example, smart meters are trying to help to track how much electricity we're using and like maybe we can like reduce the usage of electricity somewhere. Anyway, so we this concept means that everything is connected. The smart industrial devices are also connected, right? And they are connected with the like operator's level. So all the information, all the metadata is going to the operator's level. So the human can process that and can see like what's going on with that data. Yeah, basically what is industrial IoT? Yeah, it's a fancy and cool concept, right? It's a fancy and cool solution, but still it has the old security problems. If we will take a look, if we will like see the low hanging fruits and the vulnerabilities, even in new solutions in industrial control systems and yeah, industrial IoT stuff, we will see that there are also still hard-coded passwords, I don't know, super stupid cross-site scripting vulnerabilities and stuff like that. But there is something bigger. This is the basic statistics that we have identified. So how many vulnerabilities and types of the vulnerabilities we have found? As you can see, the major part goes to the Daniel service vulnerabilities, but the thing is that in industrial world, DOS vulnerabilities can be way more dangerous than remote code executions. So if there is like a technological process and the attacker is trying to exploit the Daniel service vulnerability, that vulnerability, that exploitation can stop the whole technological process. So they will start using the money, losing the money, or something more dangerous can happen. Yeah, we also found several injections, file manipulations and there is one vulnerability right here, the account manipulations. It's basically, it's not a bug, it's a feature I was told by the vendor. So the thing is that the remote attacker can disable, legimate user for like two or three hours, so the user will be blocked totally. So we submitted that vulnerability to the vendor and the vendor was like, hey, you know what, it's not a bug, it's a feature. You can increase the time like in the configuration file. I was like, well, okay, it's not going to take like two hours, not two hours, but three hours. And they were like, we can just input this thing in our FAQ document. So they can just increase the time till 10 hours. I was like, well, it doesn't make any sense. So there is no CVE for that type of vulnerability, but well, looks funny. Anyway. So basic vulnerability research approach. First we start researching the custom made protocols. It's super cool and it's super interesting to go deeper into the like custom made protocols. Then we start playing with Decom protocol and then we were playing with OPC UA. Did anyone heard about the OPC UA? Cool. Interesting. That's awesome. So OPC UA, it's a concept, it's open source type of the protocol and the way of communications of the devices. So yeah, the source code is available and basically this is like a Lego for industrial companies. So using those tiny bricks of the OPC, any company, any vendor can build like a huge system on that. And the new approach is the common solutions. So we have identified that there are lots and lots of different common solutions among the like hundreds of different vendors. So here are the examples. The first thing is about the custom implementation of the, excuse me, about the custom implementation of the XML. So we have identified that if you're inputting the random data without knowing any, you know, text, the server side returns you the, basically what are the text and what are the fields should be, the legitimate fields. We were like, okay, that looks interesting. So basically if you input like x, x, x, x, the x, x, x thing, it starts, you know, comparing if there is a field naming x, x, x with the real ones and he's like, this thing is going through the whole thing and shows like, if x, x, x is equal to like a A, C, E, C computer object and blah, blah, blah. Then we enhanced that thing and like we have found that there are like different and different. So we basically have built the whole tree of the XML. That looks great. And that basically gave us the remote code execution, but it wasn't the binary remote code execution, it was the logical remote code execution which looks better than the binary one. The second, the second example is about the OPC custom implementation. So this is basically the whole proof of concept of the Daniel of service. We have like internal feeling that there is a remote code execution behind that, but we still haven't found the way how to exploit the remote code execution. So, yeah, this is the example of how we have identified that. And you have just, you just need to send like a tiny packet to exploit the vulnerability and that's it. The system goes down. And my favorite example. So if you probably remember how my presentation, yeah, let me just show the name of the presentation right here, right? So you see like there are remote code, remote code executions and this word. This vendor didn't want me to name that word. So I decided to change that word into the other one. You will see now. So yeah, custom protocol. But first, custom protocol. So first we have identified this thing just in like ICS and industrial IoT things, but it became huge, like super huge. So there is a custom made protocol. So if you interact with that protocol as with the HTTP server, it will work with you as like HTTP server. If you input binary data, it allows you to do like some binary things with that. So what happened? These guys, they had a custom made, you know, packer for their solution. So they wanted to protect their solution from like researching and stuff like that. But for some reason, for some reason, they have removed well-known security things. For example, canary stack, like safe cookie and stuff like that. Basically, what does it mean? If you find like the point where this thing crashes, you can just go, like, you can just exploit the remote code execution like super good. So if you, I don't know, if you pay an attention, you will see that there is like AAA and so it goes like really good and fast. So it allows you to do the remote code executions. But after we have submitted the vulnerability to this vendor, strange things started happening. We submitted the vulnerability in December 5, 2016, right. So we submitted them two different remote code executions and 11 Daniels service. Then I sent one more reminder because I didn't get any feedback from them. Then I sent one more reminder and in January of 2017, I got the feedback from them that they received our vulnerability report and stuff like that. Then I was sending them reports almost every month but nothing happened. So they were just sending me back like, hey, just, yeah, thanks for your email. You just have to wait for our feedback. Then they in, when was it, May or June, they have submitted a new version of the driver but they didn't make any announcement. After, I didn't know that and our team didn't know that and we're still sending them emails and they were still replying that, hey, we're still working on that problem but the driver was updated. It turns out that even on after the driver was updated, they didn't submit the new version of the driver to the, like, Microsoft. So if you update your Windows system, it will not get the new version of the driver. That looks strange. After we decided to do this DevCon talk on this vulnerability, I have sent them email saying that, hey, guys, we're going to do like IoT Village talk on the DevCon about this vulnerability and they were like, hold on a second. We got the, we got actually the advisory published but the advisory is on the like private website so you cannot like get it like online. So you have to get the, you have to log in somewhere, get the advisory and stuff like that. They didn't want to submit any CVEs so we did that for them. And yeah, we of course notified the US ACS cert on this vulnerability because the thing is that first we thought that this vulnerability is only like in like super custom made solution and we didn't pay attention but then we start like looking deeper and wider and we have identified that it's super huge. Yeah, so those CVEs are ready. It turns out that these guys, they work with the thousands and thousands vendors under the OEM, I was it, under the OEM theme. And basically each vendor has thousands of the clients, right? So we still don't know how many people and how many companies are still vulnerable. And we don't know how to notify every, we didn't know how to notify everyone to update the driver. So the strange things started happening. We continued our research on that and we have identified several strange functions. Yeah, some functionality. Okay, so basically what if you can remotely, remotely turn on and turn off the administrative panel using undocumented API functions. What if you can remotely make a configuration, do the changes in the configuration file using the legitimate API functions again. And it will not be, so the security administrator will not see that, right? How do you call that? What's the name for that? I'm not allowed to say that word, but anyway. So it turns out that those guys were doing some stuff some day, I have no idea when. So when we reported this functionality, undocumented functionality to them, they were like, no, no, it's not a bear, it's not that thing. It's our mistake in the code. And we were like, hey, you just have a hidden functionality like in your solution, right? But like, how can we manage that? So how can we, how you cannot agree with this word? And they were like, no, we don't agree with this word. So we decided to call like not a bear thing. Yeah. This is basically what I have just said, like remotely enable and disable administrative panel. It's non-documented. And the panel is available by default on like the localhost, right? And the other thing is that basically, if you have a Windows based computer, right? And the computer is locked, right? So you can just take this thing, you know, this USB device, like it's official thing from the vendor, like it's not fake. You just plug in this thing, right? What happens next? The driver, the vulnerable version of the driver is being uploaded from the like Microsoft service, right? The, this thing opens a port. The port is being added to the like, uh, legitimate and open port to the Windows firewall. And the Windows firewall allows that port open. And that's it. That's done. Basically, right, you have like the vulnerable Windows machine with open port and with some strange functionality. So we started researching that thing. And so the, yeah, the manipulations from the configuration file. So basically you can change the, the proxies error for the binary updates. So if the attacker changed the proxies error for the binary updates, so you know what's going to happen. And we also have identified that it is possible, it is possible to capture the NTLM hash of the built-in user of like, there are several built-in users in the Windows operation system. So you can capture that NTLM hash function. And that's it. So we submitted the thing to the vendor and they were like, hey, you cannot do the SMB relay attack. I was like, yeah, of course we cannot do because like it's a built-in user. So it's not possible, but still there is a possibility to do that. So we decided to, uh, we agreed with the vendor to publish, uh, this, uh, advisory. So, but the thing is that we don't want to leave the world like, you know, vulnerable. Uh, we decided to provide like open source and free overall definitions. So they are available and you can download them and you can use the Mitre tool, uh, to, you know, to play with those overall rules, overall definitions. And you can check if your system vulnerable or not vulnerable to that thing. Uh, so yeah, the, uh, the, uh, alert is being available, is available here under this link. Link. And, uh, so what are the conclusions? So if the, the best thing is, which can help to protect this world is knowledge sharing. If you share the knowledge like everyone will be protected. The second thing is, well, if you made a mistake someday, you have to admit it. You have to admit that, well, there was a problem but we are doing our best to fix the vulnerabilities. And of course, if you are going towards the, uh, new concepts, for example, industry 4.0 or like industrial internet of things or blah, blah, blah, whatever. Well, you have to do it right. You have to put the security on the basement. Everything should be secured by design. Not like, you know, those things. And of course, if there are different, uh, third party solutions I used in, in a huge, like industrial or, uh, industrial systems or industrial internet of things, you have to test them properly. So if you are like, if there are any vendors and if you are using the different third party solutions, you have to test them first. You have to see like the source code or you have to do the vulnerability research of that. So you have to work, you have to do what you have to do. Okay. I guess that's it. Thank you. Yeah. So if you have any questions, I will be happy to answer. Yeah, yeah. Oh, it's different. It's different. Uh, our, uh, so our research group is working on the, uh, so we are served with like, we're like a computer emergency response team. So, uh, what do we do? We do the like vulnerability research incident response. Uh, if the customer asks us to do the penetration testing, we do that. So it's like, we're, we're in the research department, the research group of people. Okay. Thank you. Yes. I can't hear. Uh, so, uh, yeah, let me show you. So, yeah, you're talking about like this case. Um, yeah. So basically they have turned off, uh, not turned off, but they didn't use, uh, for example, safe cookie. There, there, uh, there is a special, uh, mechanism. It's called like safe cookie. And they didn't use that like, uh, when they were writing us, uh, the code for that binary. And like, they didn't use like a really common and world-known, uh, security mechanisms. Yeah.