 Hey everyone, as you start moseying in we're gonna have Berting, he is an independent security researcher. He's gonna talk to you guys about industrial protocols, it's gonna be a really fun talk, I hope you all enjoy it. And yeah, as you start moseying in, I see the camera guy has given me the okay, we'll just start kicking things off, so please give Berting a warm welcome and everyone enjoy themselves, thanks. Okay, cool. Hello everyone, welcome to my talk. This is about, well, as the title says, mixing industrial protocols with web application flaws in order to deploy devices in the internet, which is I think that I used to do all the time for like 10 years ago, I mean something really crazy. Let me, that too. Okay, here we go. So, okay, why is so fast? There is, so fast, okay. Okay, hello, my name is Bertinas, they present me, this is my tutor, I'm working as a security consultant, professionally, network engineer, security research, device security, protocol security, basically all of my research is based on remote exploitation all the time, I mean, all the things that I do is remote and always, all the devices that I use to exploit are connected to the internet all the time. Okay, agenda for today, the motivation for my research, how I started, how I found this, and how I developed the exploit and all the stuff. I'm going to be talking about modern magnet devices, the security problem in those devices and then I'm going to be explaining how to use magnet protocol itself as an attack vector for this kind of devices. The fundamentals for magnet because in order to understand this, we need to recap all the things about magnets, how it works, how it's designed and all the stuff. The theory and the technique and the exploits and the conclusions. At the end, there is a bonus track that I decided to include in this talk, it's an RCE and industrial router, yeah, that's critical as usual. So, the motivation about this, there is a lot of fun, a lot of fun in industrial protocol security. Usually, you can on off things, start stuff, start and stop stuff, read critical data, modify critical data, inject malicious data, execute malicious stuff and so on, all these remotely, from your home, from your, I mean, your hotel room, everywhere in the world. So, I start playing around with many of them, of these protocols, visible for same changes and some of them are invisible. That is a fun fact that many researchers ignore because they think that current search engine are indexing all the industrial protocols now, but that is not true because there are a lot of new technology, there are a lot of new devices with proprietary protocols. And these protocols are based usually in UDP, TCP, so you can, of course, scan the internet for these new protocols and have some fun with them. So, please keep in mind that thing that there are security, I mean, there are industrial security protocols or industrial protocols that are not being indexed by current search engines like Kashodan or Sumai, and people don't know that. So, the following is the results of ours are reading, documentations, analyzing services on the internet and testing on common things, trying to find out new paths for remote data injection and web application services for specific devices using the BACnet protocol. Okay, BACnet previous research, there are a lot of that about BACnet. I mean, several talks about that you can find out, it's always the same thing, like on, off, start, stop, attacks. We know that there is no security in this protocol, it's basically plain text, there is no authentication method. You can perform actually BACnet network scans remotely to the BACnet topology infrastructure. No web applications issues found until today in this talk. I was trying to figure out if someone else years before tried to do something that I am going to show you today, but I had no look, so basically this is something new. Okay, today I am introducing a new attack vector in BACnet devices, this is remote, and last night I found another brand affected by this curiously, so this is a travel touch thing. I mean, there are several brands affected by this thing, but I don't know, and we don't know exactly which they are, we need to find out. You don't need tools to do this, it's just a simple script, it's a crafted attack, very, very crafted attack, it's a stealth UDP base, and you can get persistence, and finally code execution in browser, which is really cool. This thing doesn't work here, I mean we're talking about web application, but this thing is not capable of finding these kind of things, so if you think that this is the thing, you are wrong, I'm going to prove that today, so please keep in mind that this thing doesn't work here, it's not prepared yet. Okay, so brands affected by this issue discovered until now, this is a traversal issue as I mentioned, the first brand is called RLE Technologies, this is a brand who manufactures devices for industrial purposes, protocol converters, industrial routers, blah, blah, blah, that they can, which I don't know, which is the relationship with MyKwai, which is a Hong Kong company, they are using the same kind of server in both brands, so they have one device here and another device here, and they are using the same technology, so they are affected by the same issue. Two brands using the same technology. There is another brand which is not included here that I found last night, which is called KMC Control, it's affected by the same, but was found last night, so it's new. Okay, this is the first device that I was able to exploit with this thing, everything started here with this thing, the RLE protocol converter, what this thing does is trying to, well actually not try, it converts a magnet protocol to, not boost protocol, this is a protocol converter, when you don't have a way to communicate with devices, this thing helps you to modify this kind of protocol conversion and you will be able to reach devices, through this thing. Okay, the devices affected by this issue are this one graphically, Daikin and MyKwai, they manufacture chilling, big chillers, chillers, that's it, chillers. And those devices are connected to the internet, they have a web application in order to manage, configure, set up the whole thing, and things are just getting bigger and bigger. Okay, this is an example of a magnet topology, how a magnet topology is deployed in infrastructure, so our goal today is, or an attacker goal, is infect the engineer web browser, why the engineer web browser, because he is going to be connected to this kind of devices in every time, so usually those engineers, or these technicians, has access to another set of devices, so if we are able to execute code and their machine browser probably we could still, other things that could be more interesting in this kind of particular attacks. We're talking about like an APT attack or some kind of thing, I don't know, but if you get persistent in the technician or machine, you could probably pivot to another more critical devices in that infrastructure or probably another more critical computer. This is the idea that I have with this. Okay, this is taken from the magnet.org tutorial, basically the official documentation of the machine, the documentation from magnet, and there is a little note about security, because when I started this I was interested in how the security of this thing works, but I found this, so there is a little discussion of security in this presentation. We have assumed that all nodes are trusted, security will obviously be an important future consideration, for now I assume that all devices are sitting behind a firewall that does packet filtering and the environment has well implemented restrictions on the software that can run inside a firewall. This is all the thing that this guy said about magnet security, you can find out in that link, this is all that you will have, that you will find about security implementations and the protocol itself. So it means that there is no authentication methods, there is nothing to protect the protocol itself if there is no firewall very well implemented and infrastructure. So our goal today will be the following, a remote attacker from the internet has access to the device, but has no access to the web application, but has access to the magnet protocol and he can read and modify things using just the protocol. So let's start with the magnet specs and in comparison with the OSI layers, the magnet works and the application and network layer and of course IP, IP protocol. The port is 47808, it's UDP based, no complex security mechanisms as I said, no CRC, no integrity checks, no hash, plain text, read write capabilities and it's completely open in the internet. You just need to perform a query in some changes and you will find out that there are a lot of devices connected. Okay, the magnet structure is basically magnet by the IP, the first layer would be the VUVLC or magnet virtual local control. The third layer, the second layer would be the MPDU, network protocol data unit and the last layer would be the application data unit which contains all the information that we need to inject to the device. The magic happens there. Okay, let's talk about the first layer, the magnet virtual link control is basically two bytes, oh excuse me, four bytes, it's four bytes. The first byte defines the type. In this case, magnet IP which is 81 and hex, the second one defines the function. In this case, which function we would like to execute in the communication. And the last two bytes define the length of the whole packet. So you need to sum the three layers and put the resolve in that first layer in order to create a correct magnet packet. And then send it to the network and get the response. If that number is not correct, you will get a more frame packet. So it's not going to work. This is a graphical representation in Wireshark about the first layer, the magnet virtual link control. You can see the function, this is our original unicast communication. And the two bytes are the length. Then we have the magnet network protocol data unit. This is a representation according to the magnet wiki button. Practice is just two bytes. Like this. So it's just telling you the version that you need to use and the control. So in this case, we set up the byte to four, which means we are expecting reply from the device. So if you don't configure this control byte, you probably, you could, you couldn't get the reply back to you if it's not properly configured. So you need to read the documentation and start constructing the packet byte by byte. And the last header is the magnet application data unit. This thing is the last header and contains a variable length that also should be specified in that, in that header. Otherwise, you will face more phone packet issues again. This is how it looks like in Wireshark. One important thing here is the service choice. The service choice is the byte that allows you to read or write things and the magnet device. Okay? The magic is in the APU header that allows you to read or write values and the magnet data structure. Okay? Here's what I'm talking about, the magnet service choice. So you have all those values and bytes that allows you to set up how the communication is going to be executed. So in this case, we're going to be using the 12th number value, which is zero C and hex in order to read, just read. Right? In order to read, right, you need to set up correctly the service choice byte. At this point, probably you're taking a look into the fourth in byte because the fourth in byte here allows you to restart the device. If you send that byte, the device will just restart. But we're not going to be talking about this today, but keep in mind that this can be possible, just sending a single packet to the network. So in order to read, it would be zero C and hexa. And for write, it would be zero F. That's it. This is how a read packet looks like. You will see the read property configured there and the number 12 in decimal. Okay? The values that we need to read and write will be the magnet objects. A magnet object is unique in a given device. It's a combination with many properties, specifically the when you create a device and a magnet device, it means that every sensor, every in-out output, input output, will be created in a single device. This device has a name and this device has his own properties. Every sensor in the magnet device has this segmentation. Like specific, may I compare this with profiles? It would be kind of a specific profile. And the property of each profile can be modified, remoulding. Okay? The object identifier contains the property identifier. Basically the string values represent the new name and readable strings like location, device model, device name, and so on in few words or targets today. So in this case, we are reading the specific object, the object identifier, which is a property identifier. It's kind of confusing, but one thing is up on the other. Property identifier has an object identifier. So if you see this is encoded as a character string, the object name, the location name, application software version is character string. There are several tools available you can use in order to read and write values with magnet. There are a lot of magnet clients. But the purpose of this thing is go deep and do this without tools in order to understand exactly how it works. You can do this with any language that supports okay communication. Okay? Let's take a look at how this looks like in execution. So this is an example of how our read package looks like in a really raw way, in a really primitive way. You can see the four bytes, the first layer, the BULC, and then two bytes, the MPDU, and then the biggest layer, which is the APDU, which is a lot of bytes, two, four, five, six, nine bytes. Okay? So if you want to read a property identifier and an object identifier inside that thing, you need to send a packet that looks like this. You will see the service choice which is 12, properly configured, and then the object identifier. The object identifier is the only thing that I found as a security mechanism because you cannot read or write without that value configured there. So in this case, the device is using a 3,000 string, excuse me, um, uh, integer in order to execute functions. I mean, you can, you cannot execute something without that number specified in the packet. So for example, if you try to write values there, and the value is not matching with this value of 3,000 in the device, you're going to be able to write something. So you need to first, uh, known this value in order to then, uh, write property. Okay, let's take a look in the demo. Okay, I, I develop a, um, a tiny script in Python that perform all these things that I've been talking about. You can see the first, um, the first packet will be this thing. So this thing is just asking for the object identifier, and then the second packet is asking for the vendor name, uh, the software version, and so on. So it's like, uh, uh, seven functions. Each packet is for, it's function. So let's see how it works. Let's open the wire shark in order to see the communication flow. Okay, you see, there is a filter for magnet. I'm going to execute this. And you see the communication. Correctly, um, um, I'm performing communication with the device remotely. This is a real device connected to the internet. And, uh, I am asking, I'm asking him information regarding magnet. Specifically, I ask him him for, uh, his object identifier. You will see he, he asked me like, uh, yeah, my object identifier is 5,000. My vendor name, the firmware version, the description, the location, model name, application software, and other object name. All this information is printed here on, on, in the output of my script. This is, uh, my quite shiller, a big shiller for sure. And this is how the communication works. When you understand this, when you, in practice, are able to do this, you are ready to write values. But which values are interesting? I mean, why can I do with this? That was the first question when I tried to figure out, found something in the protocol and the web application. Uh, at the beginning, my purpose of all this whole thing was not to find web application issues. Uh, was to figure out how to find something in the protocol itself. I mean, execute the stuff. But in the process, I found something cool. And this is the result. Okay. This is how you can, uh, communicate with the devices. We just, with a simple script, as you can see, uh, all that I did was just read the documentation, understand how the protocol, uh, works, and then, uh, put it in code, in just, uh, a, a single socket connection, you're sending rowites, and then, splitting the response in order to show, uh, the plain stack data coming from the device. Okay? Cool. Let's continue with the thing. Okay, let's check out the response. At this point, you will notice that the communication with by the, when the device is successful, also the response back contains a specific value for the object identifier. Remember that, that, that number. Keeps the value in mind because we will use later in order to write. It's really important. Okay. Now we know how to, okay. Now we know how to read the specific values from the bag net data structure. But the cool thing is that we can modify those values. And also, the same values are being taken from the application to represent the stream values, I mean, in the, in the web application from end. So this is cool. Because what if we could, uh, modify this stream values for pieces of code, pieces of Java, HTML or JavaScript code. In theory, this could be works or couldn't be, but at the beginning, I had no place to taste this because that was just in theory. Uh, I needed, uh, a real device connected to the internet with this scenario, uh, in order to prove that this thing works. And, well, I found it and, and this is what it is. The right property is tricky. Sometimes objects are restricted to be modified, but most of the time the property value location is able to be modified from the bag net protocol. Um, well, the thing, the, the same thing about the device ID. Okay, in order to write, the property, uh, tells you that you need mandatory specific values like the object identifier, the property identifier and the property value that you want to modify. So let's see how we can modify stuff. So this is a real thing. This is a real application. This is a real device. I'm quite sure connected to the internet. So, uh, when I found this, uh, what's the same impression as you? There is nothing there. I mean, it's not showing nothing, but if you right click on it and you check the source code, you will find gold. Why? Because here, first of all, there is a password. Um, let me check. Password for restart is one, two, three. Yeah, this is out of scope today, but it was a kind of, uh, nice, nice thing to find. And then if you take a look closer to this thing, you will find something really cool. Awesome. Yeah, yeah, yeah. Let me see. Yeah, that's it. Okay, let's take a look at the password again. The funny part. Okay, there is a password for restart, one, two, three. Uh, but here you cannot see any. I mean, on the main page, you won't see any. You just need to check the source code in order to find cool things. But that was not the thing that took my attention in the first place. The thing that is interesting here is this. The location. The location is Las Vegas. Well, I put it this for, uh, demo purposes. But here, uh, I'm gonna do this with, uh, this thing. This is, uh, magnet client. And you can do this from here. And now I change the location, the value from the location, right? So if I reload this thing. Okay, there you go. Now let's check again the source code. And you will see how the location has changed by IOT. You see, now we are in IOT village. So I did this from magnet, uh, protocol. Uh, the device has no security. Actually there is no access for it. But I have access to the protocol itself in order to modify stuff in the web application. So now this is, this become a nice vector attack. A nice vector attack for, um, HTML or JavaScript code injection. And we are not using Word. That's the cool thing. Okay, so now we know how to write. And now let's break it down to exploit. Okay, the application is taking values from magnet to be represented as stream values in the web application from end. Those values can be modified from the magnet data structure using the magnet protocol write capabilities. And good theory is I replace the stream values for JavaScript code. The JavaScript code will be executed just in theory at that time. Open up the source code, check again the value of location tag in the device. And our goal will be the following. Replace this thing for JavaScript code. And the result will be an stored, uh, cross-site scripting in the device with application in those tags. There is no need for a special XSS payload, a single alert in the script tags. It's not figured the cross-site scripting. So, um, the application probably is password protected. So as you can see, actually you don't need to touch it at all. This is kind of cool because I didn't need any special, I mean, with the word application, actually was not touched at all. Everything comes from the magnet. But as I said, no problem. Magnet is available to inject code. And now we know we should place or exploit. So let's see the demo. I have a video because, you know, here we got the same device. And first of all, read, of course, you will see the location. It's Vegas. Check again the source code as I did. You will see the tags. All this information can be modified to description. I mean, you have several places to put JavaScript code. That's kind of thing. But the cool thing is, as I said, the location value. Now let's change Vegas for a cool payload there. Okay. Everything is still fine. Now let's take a look to our exploit. So our exploit would be this way. The same thing, the four bytes, the two bytes for the second header. And the APDU with the biggest header, which includes our payload, our JavaScript payload, but encoded in hex because it's going to be sending on the network. So you just need to send that. Don't expect a reply or anything because it's UDP. And the values are going to be injected in the web application. So, okay. Now I just send the exploit. You will get the simple acknowledged reply from the device telling you that, you know, I received your packet and everything has been written. So you're good to know. If you follow the UDP flow, you will see our payloader or a script other payloader. And the acknowledgement from the device is expected. So now if you reload, so there is your code executed in the web application. And it's persistent. I mean, this thing is going to be stored forever there. So every time that someone connects to the device, it's going to be getting infected or something. Okay. Other things that you can do with this is, for example, leak, internal server routes. As you can see, config objects input that comes from the device. So you have a path or leaks either. You can take advantage with magnet. And also, check the device description for each profile. So, for example, this was an elevator free machine room temperature. So you can nominate what's exactly which specific device does in the device. So conclusions for this part. The techniques allow you to inject JavaScript without dosing the web application at all. This JavaScript protocol base injection technique. In this particular scenario, we don't need credentials or access to the web application. You just need to inject the payload and say goodbye. Several protocols are also affected by these kind of issues. But, you know, I cannot publish everything in one talk. Several magnet devices with the port 47808 are vulnerable to be modified remotely using this magnet protocol. And the number of current devices affected is unknown, not lit for me. Always, there are probably new technologies affected. There are several tools to read and write. If you're sparing issues, try to reproduce the vulnerability this way. Check your back lens or operation code. So, finally, the bonus track. This is something that I found a couple of months ago. It's basically an RSCE vulnerability. And those devices from this brand called Forfade. So, Forfade is a Chinese brand of industrial devices. They manufacture a lot of stuff with 3G, 4G, industrial routers, CIGB, a lot of that thing that is related to industrial stuff. And, of course, they have devices connected to the internet. I found something really cool here, which is an option to execute commands. At first place, you would think, okay, just put a command there, put a net card inside, and probably you could get a reverse shot back, but that doesn't work. So, I need to figure out how to execute code there. And there is an option here, an application, this option called commands, administration commands. And you will find this. You will find this. Okay, this box, this command shell allows you to execute Linux commands. But as I said, if you try to execute a net card or something like that for easy stuff, it won't work. It won't work correctly. So, I had to figure out how to execute commands here. And I found out this payload that creates like the script or something. And then you will see the net card command included here pointing to my IP and my port. So, just copy that thing, paste there, copy, and run the command. Here you go. And you will see the shell back to me remotely from the internet. And there you go. And also, you can perform a cat. You know, the same thing as usual, ATC, password. And that's it. Well, these kind of issues are always in those kind of devices. It's the same thing all the time. It's really, really easy to spot RCEs. I don't know. The thing continues. I mean, the research continues. Well, I think that is done for today. Any question or something? Just let me know. This is my Twitter. If you want to follow me, I always publish stuff related to this kind of IoT stuff, OTS stuff, ICS stuff. So, thank you for your time. Welcome.