 Hey guys welcome to the IOT village and the 410 talk. As you can see we're going to be talking about IOT the gift that keeps on giving and this is presented by Alex Balan aka Jay. Let's do this thing. Thank you. So first of all soundtrack because during the last talk there were a bit of problem with a bit of background noise so can anybody in the back hear me okay? Yeah, thank you. So thank you for taking the bait with the first slide first of all. And also big shout out to the guys that actually hacked this thing and they're actually in the room right now. So in case you're wondering the machines in the Scissor Palace run Linux these were taken yesterday. Okay. So we're going to talk about three major things. First of all the crazy state of IOT. Second we will detail a bit about how we did our research, what were the results, what's the impact and how much of the entire planet is going to be impacted by this. Some of you will already know what we're talking about and I will ask you to look kindly on us and our methodology. Some of you who are not familiar with IOT security will learn something today. Because we will take you step by step through each step of our research. How we did each single thing and how we achieved each single result. So stay tuned because if you want to learn how to hack IOTs now is your chance. And third conclusions and you will learn why the presentation's name is the gift that keeps on giving. So chapter one the crazy state of IOT about a few months ago I rented a car. I registered it with my name, my email address. I passed it on to the car rental and then after about one year I keep getting emails from the car saying the mileage, what the car has done, what's the status, the pressure in the tires, whether or not it needs revision and that's probably because the car rental didn't bother to register it from my name. So mind you up until today I still get emails from that Chrysler with its status. And a very important thing that I would like to point out is that everything becomes more and more smart. This is kind of a cliché. But you probably have no idea the rate at which this is happening and how little choice we have in our choices right now. When I say that everything becomes smart I mean that we will not have the option to buy non-connected devices. And to give you just an example we used to have parallel port printers, then USB connected printers now all printers are network connected. We will use the network connected. And when to that stage without even realizing it, we took it as a benefit, it is a benefit, but it's a herald of this new era in which everything including your upcoming glass of water will probably be monitored by something. Connected. XBOX without connectivity doesn't exist. I guess there's no dumb TVs anymore especially in the U.S. Maybe in some third world countries like other countries in Romania. So it's very important on the strength that IOT is not going to be optional. It's important to realize this. So these are not picked at random. All of these have some kind of vulnerability discovered in them. And that smart power outlet for example Feelsin. So, uh, these are not picked at random. All of these have some kind of vulnerability discovered in them. And that smart power outlet, for example, has a command injection, remotely exploitable, uh, from anywhere in the world. As, as a fun story, I was at this, uh, IOT builders event once. In, uh, February last year with a colleague of mine. Uh, by the way, it's nice to see so many familiar faces. So, there was these guys that made a device that would make you be calmer or more energetic. Now, it's the actual equivalent of electronic drugs. When you put it on your head, uh, you control it with a mobile app and that mobile app talks to the cloud and that mobile app controls the device through Bluetooth. And it can make you calmer, much like weed does, or more energetic, much like something else that I did never try. Uh, and the problem was that, this is the thing, I put it on my head, and I said, I said it was more energetic because I'm usually a very mellow person. All my friends know that I'm very calm, very chilled, very relaxed. And, uh, I turned the dial to one, two, when I got to three and a half, I passed out. That guy over there was with me, he can, he can testify to that. I passed out, the guy grabbed me, and for about 20 minutes, I was unconscious almost. I was like, oh. And I think that's very dangerous because that device is connected to a mobile application, is controlled by a mobile application, and that mobile application talks to the internet. So, if you can, if you can hijack their cloud and send commands to that mobile application, you could effectively be able to fry all their users' brains at the same time. And that's kind of screwed up, it's like science fiction, like Kingsman, but it, it's actually theoretically possible now through companies such as this. I'm not saying that what they're doing is bad. All I'm saying is that maybe they are not ready to market this without a serious bug bounty first. Um, the most combinations that we've discovered is, of course, undocumented hard-coded passwords, Wing Bling Mirai, Wiccord and encryption. There's a, there's a lot to be talked about this, and I would like to focus more on the research part. Command injection, this is an example of a command injection in a smart doorbell. They have a Dell file CGI, which calls a system command called RM on Unix. Right? And you can just, you know, send my column and append another command to that. Wi-Fi configuration hotspots that remain open. Worst of all, and an advice to everybody, if you want to evaluate how good a solution is, look at the way they update. This is the simplest thing that you can do. If they do automatic update like Nest, Amazon, and a number of other good products, they're okay. If they ask you to upload a firmware binary file that contains the update in an antique interface, that means that product is shit, you should throw it out. I'm not even joking. And the most dangerous issues discovered and will be shown today, UPFNNP. So, just so I can, uh, get a feel of how much I'm supposed to debate about this. How many here know what UPNP does? Okay. A good chunk. Thank you. So, for those of you who don't know, UPNP enables the device behind the router to tell the router to port forward something. Effectively, exposing that service directly in the internet. So you put this piece of this nice camera in your house, it's going to tell the router to the port forwarding to you. And that being said, I'm going to start this, just to make sure this is part of the demo, right? This is the router that's going to be used for this demo. And my laptop simulates the internet. Okay? My laptop provides internet to the router, connected to the router's external interface, the one interface, and it's going to look perfectly fine. No ports open, rock solid. The end map is going to take a while. So in the meantime, hang on, there we go. Uh, another big issue is device cloud mobile app cloud synchronization. In this process, there's a lot of sanitization to be done. A lot of user input sanitization to be done. And unfortunately, 90% of the cases, it's not happening. Uh, it's not going to be part of this talk. We have another paper on it, probably to be presented at another conference, but it's really, really interesting. It's very, very fun. So, um, one of the key messages that I would like to send out. Most research that's being done right now on IoT is focused on proximity based attacks. Uh, stuff like Bluetooth men in the middle. You know, hijacking the key exchange, key replays, this kind of things. Or getting root access, you know, through some command injection in the local interface on your laptop. And I'm not saying that's wrong. That's really, really cool. I mean, it gives you the opportunity to share your knowledge with the world and, you know, make that device better. But you know what's even cooler than that? Mass hacking hundreds of thousands of devices. Because so far, it's been done with Telnet. And that's pretty, pretty trivial. Am I right? That's like the basics of the basics of the basics. What if there's another step to be taken in remote compromising hundreds of thousands of devices? Okay? We should look at that. And what if there's one more? Probably more complicated, but once discovered, it can be reused by the bad guys to compromise hundreds of thousands of devices. The world does not begin and end with Telnet when it comes to mass hacking. Right? So to that point, I would like to make an analogy. IoT's are small computers with a stack that looks like this. Hardware on operating system and an application layer that companies develop poorly. Because they don't know any better. It's not their fault. Much like, is anybody familiar with this stack? Is anybody older than 30 years old in here? Okay. So Red Hat 6.2 VU FTPD. Ring a bell to anybody? It was one of the most popular exploits in 1998, 1999, something like that. I would like to recognize that it's virtually the same stack if you think about it. If that IoT is exposed on the Internet from a hacker's perspective, it's the same god damn thing. They don't care if it's IoT or WordPress. Much like this one. IS 5.0 Windows hardware. Much like this one. Subway hack. Right? Or much like this one, hardware, whatever, whatever application that can be hacked. I would like to emphasize that if an IoT is accessible from the Internet, from a hacker's standpoint, it makes no god damn difference if it's an IoT or a WordPress. They will command execute it, add it to a botnet and either use it for spam, DDoS, Bitcoin mining and whatever the hell they do. They don't care if it's IoT. So do not treat IoT's differently. Have a focus on IoT's which are exposed on the Internet. So that in mind, IoT's have a slight addition that kind of increases the attack surface and that is application cloud application on the IoT communication. And there's a load of vulnerabilities that can be discovered in this handshake. So why that is bad? Well, because there's no standards in this industry. The FTC is trying to develop some standards. I saw this really great talk by Aaron Alva. I hope I remember the name correctly from FTC at Black Hat. And they want to develop standards and they want to develop a certification for IoT. I salute that initiative. I would like to be part of that. We would like to help. So that's great. The lack of standards in building these devices is awful. It's the main cause for problems. And obviously each company builds their own stuff and they have no idea what they're doing. So chapter two. We come to the fun part. From China with love. We have these two devices here. I hope you can see them. It's a webcam and a smart doorbell. So step one. You take one standard links router. You set up the application. And I would like to point out one step in the setup process, which is bad resolution. But basically it says to protect your privacy, please reset your password. Which is great, right? It's a good thing. And you're going to go saying, oh my God, this application is taking care of the security of their users. They're enforcing a password reset so users do not have the same passwords everywhere. Good job. And it's awesome. But as we're going to see later on, useless. Okay? But remember this step. And then you blah, blah, blah, finish the setup. The setup process is the same. And that brings me to the first thing that I want to point out. They are two different devices. We do different purposes. However they have a thing in common, video streaming. So as it turns out it's the same firmware. It's just a different coating on top of it. And as it turns out this very same firmware is integrated by, I have no idea how many other vendors that OEM from these guys. So different colors, different buttons, different things, but the same binaries and the same firmware. So that means that everybody, it's not going to look like this. It's going to look different. It's not going to look like this. It's going to look different. But if they have that firmware embedded into them, they're going to have the same vulnerability. So the first thing that we noticed is that from a perfectly good router, and this is the part where I plug something in, this, all 1000 ports can, and actually just so you can see live, wink, wink. So no ports open on the router initially, right? I'm going to give it a minute to boot up because after that the same router is going to have two open ports. Why? Because of god damn has to be killed with fire and brimstone. U-P-M-P. I'm very, very serious about this. U-P-M-P is, I think it's one of the main reasons where IOTs are going to get hacked like crazy. If your router supports U-P-M-P and the device is retarded enough to ask for port forwarding, your router is going to do it. And that device will effectively be exposed on the internet. Much like these devices which are vulnerable are right now. So out of curiosity let's see if the thing booted up. The same end map. There you go. Port 80 open, port 554 open, port 1935 open. And they weren't open before, right? I mean no tricks, no bots, no coconuts. You guys see nothing up my sleeves. So that's the first issue. And it's a big deal again. Next. Shodan said that this has great potential. The web server said at the time we asked 135,000 devices. For the RSTP server we found 147,000 devices. And then what we did, we took all the IP addresses. We did a differentiate between them. We took out the unique ones to make sure that we were accurate. We didn't just add them. We just added the unique ones. And we ended up with the final total of Unix, 228,808 devices exposed in the internet with whatever we're going to show you next. I know, right? How messed up is that? So we got pretty excited obviously. We were like, this is awesome. So we started to do the basics. Basics being wire sharks, the way they communicate, taking the part of the mobile application and all that blah, blah, blah. And at some point we realized that we have become accustomed to a number of stupid things. If you discovered the kind of things that we see in IOTs in your web application for your company, you would take down the server. But we realized that we didn't care anymore because we've grown accustomed to bad coding because of these guys. For example, they have encryption in their communication with their cloud, but they don't have any encryption in the authentication process to the web interface or to the video stream. So basically if you connect to the video stream or if you connect to the web interface, that has no authentication. Now, we all feel that that is lame and ignorable, but in essence it's because we got used to these devices being shit, right? It's not because that's the way it's okay to be. It's because we got used to these devices being crap. And I don't personally think that that's okay. That's something that has to change one way or another. So we stumbled across this. We have an authentication interface on web and an authentication system on RSDP. What do we do with an input field? We fuzz it, right? So we thought that we're going to have a lot of fun with it, but unfortunately it crashed on the first try. So, yeah, that happened. And again, this is stuff that can be done remotely from the internet on any of those right now. So it's kind of bad. The RSDP server though didn't crash just yet. As we're going to see later on, they actually did something even more stupid in that place. But you know, security by obscurity. We thought that the, you know, it was okay, but it wasn't. So, um, what the crashes smell like? Right? Right? Right. So we needed the binaries to see how the crash happened in order to be able to reproduce it, in order to be able to see if we can achieve remote execution. And obviously I wouldn't be here if we couldn't do it, so spoiler alert, we did it. But let me just tell you how we did that. Um, first of all, so this is again, I promised a quick crash course if you want to, you know, do this kind of thing is very easy. One of the key takeaways from this presentation is that IoT hacking is trivial. Everybody should be able to do it. Everybody should do it. And maybe then we're going to have, you know, safer devices and more awareness in this field. So we hooked up to the serial, they had a serial, uh, it booted up much like you would with a system. I'm sorry for the low resolution, it basically says login. So, yeah. This is what we got on the serial interface. Uh, we didn't have any credentials yet. So what we do when we don't have credentials, we try to hijack the boost loader. Much like you would do on a Linux machine when you would pass parameters to init and say init equals beam bash or whatever in order to reset your route or somebody else's route password, right? So it's the exact same thing with IoT. You just pass the boot loader and pass parameters to init. And I'm sorry but you're not going to catch anything. Um, we got a dump shell exactly like you get in run level 2, right? I think. On Linux. And, uh, we added a telnet service to the start up script. This you can probably see. And then we got this. So again, this is basic stuff. It's simply because they do not protect their boot loader. Some companies do, most companies don't. You should probably be able to do this with almost all devices. So, the first thing that we saw was, unfortunately, and do you remember that slide where they asked us to change the admin password? Yeah, so we did change the admin password. But when, what we discovered afterwards was that they had two more users backdoor into the thing. Like with user user and guest guest. There's no documentation about it, absolutely nobody unless you know where to look knows about that. So if you guys want to see some live streams from people houses, don't do it because it's illegal. But if you don't care about that kind of thing, just show down the thing and then user user guest guest. We haven't tried it ourselves of course because our legal department didn't allow us to do that. But we heard from a very reliable source that it works on 99.99999% of all of those devices. It's not, I'm not proud of this. I mean, it's not great. I hate this. It shouldn't happen. But again, it's the sad state of things. I would expect that after this talk, this to be popped on INSECAM.org if you're familiar with the website or that wall of webcams. These are easily very easy to add on those kind of websites because of these things. So what's next? We wanted remote command execution, right? As you can see, they decided that they want to be monolithical and have one binary in which they stuffed absolutely everything from web server, video server, authentication mechanism. You name it, everything is embedded into one binary. Which actually, unfortunately when you hack it, when you do anything to it, it reboots the thing. But you are able, as you're going to see, to execute something. So debug time. Since we got system file system access, it had an SD card support. We copied the entire file system to the SD card and we got the binary and we started to look at the way things work. So authentication works like this. It checks the URL, HTTP, IP address, question mark user, password, blah, blah. And those blah are being parsed by that Libre sparse data function, right? So what's going to happen is that Libre sparse data is going to complete a contact of those two arguments, user and passwords onto the stack and it's not going to check their length. Now, as you can see below, there's only 460 bytes allocated to the stack. So if you feed it more than 460 bytes, it's going to crash because of auto bounce. So what we needed is to be able to exploit that. And now comes a fun part. So pay attention to this one if you're sleeping wake up because the system has ASLR enabled. So that was kind of bad for us because if ASLR was enabled, we wouldn't know where to inject our code, right? So that was kind of a big thing and we were like, okay, this sucks. So then we just for the sake of it, we checked the binary with check file. It's a program by some guy in Germany. And who is familiar with this? Pi stands for position independent executable and it's a flag when you compile a file that allows ASLR to move the program to put it at different addresses in memory because that's what ASLR does. ASLR prevents you even though you're able to crash a process, prevents you from executing your code because it always places the program at different memory addresses so you're not going to know where code is. So you're not able to exploit it. However, they bypassed ASLR because that's how they roll, man. ASLR is for pussies. So yeah. They compiled it without position independent executable and as such, it's always loading at the same address. So from that point onwards, with the ROP gadget, we actually had system available. We called system and this is the exploit. Actually, this is the exploit. It's very complex as you can see. Very big. This can get root access on 200,000 devices worldwide. Actually, not this specifically because you're going to need different targets for different devices. So it's the same method to get the targets but this is one memory address, this is another memory address. So yeah. Okay. That's it for this thing. The RSTP was a different issue. As you recall, we weren't able to crash it by just, you know, sending garbage to it and that is because they rewrote it. They actually rewrote digest authentication in their own way. And obviously they did it badly because you see these fields which are basically user field and value. Digest authentication has multiple entries of field value, field value, field value, field value, field value. Now this field value thing is implied to have 256 bytes. And obviously the way they wrote it is that they just parse it with scanS and they do not validate the limit. So if you put in field value, field value, anything beyond 256 bytes, you're going to crash the thing. So it works. You just send this kind of string and this is the exploit for RSTP. We use the same, it's the same binary. So we use the same rub gadget, calling system to execute our commands. So yeah. It's time for demo. So I will just to recap my setup here. The laptop is the internet. The router gets internet from the laptop. So the laptop is connected to the router's one port, the one that's supposed to be filtered. And these devices are connected to the router. So what we're going to try to do is get root access. Actually connect back shell because you cannot, you know, move past the router. We have a metasploit handler listening here already. Wait. That was not supposed to happen. Okay demo gods. Let's see what's happening here. Okay this is that. No worries. So I have a quick and dirty copy paste file because it's a lot of stuff. So you can see we execute our exploit. We, as a target we have NIP22 which is the camera. The IP address which is the router IP address which would be the internet of accessible router IP addresses. And then this is the command between codes. TFTP get jena which is our binary as a tribute to a great poet. We write it to a local file called tmp slash jena and we get it from a remote server which would be my laptop. Then we make it an executable and then we fetch another RCS which is like the script that executes a startup from the TFTP server replace, make a copy of the original RCS, replace the original RCS with ours which actually executes jena at startup. Because the way we do this is that is because the thing crashes when you, when you get the command execution. So we need to add it to the startup scripts because we're not going to have time to do anything on it otherwise. So, here's to the demo gods. Okay, it's supposed to crash in a couple of seconds. One thing that we've added just to see how that script looks like. So we have to add a slip 20 in the init script because it wouldn't, it would execute earlier than the network interface would get up. So that's why we have to wait a little bit. Did it reboot? Okay, it reboots it now and there you go. Shell. So sessions minus I3, I are rude. Yep. So I will take commands from the audience for one minute. Who wants to see stuff like it's an arm and I'll show you where the juicy stuff is in MTD. And then the first thing is RT287STA. Not this one. Yep. So Wi-Fi credentials. And the nice thing that I was telling you about earlier, could we move the projector just a little bit? Thank you. So, I'm going to, does anybody want to run any commands on it? Seriously, it's okay. No? Okay. So we're going to close this session. Oh, wait, I forgot something very important. Yeah. It's the same exploit for RSTP, it's the same thing. And it's the same thing for this device. The only difference is that you have to put a slip 60 on this one because it boots much slower than the other one. So you have to execute your script in the, in the start-up system a bit later than usual. So put a slip 60, maybe slip 70. So you give it time to boot up and get the network interface up. So we have another shell because we are at start-up. And what I want to do is clean it. So just, so it's safe. Okay. A board session. And there you go. So I have one comment for the people who are probably old, as old as me or older. I hope they'll get this reference. 20 years ago, you could tell that to a Solari server type root as password. And you could tell that to a Solari server type root. And roughly 16 characters as password and the logging process would crash and the system would log you in as root. So 20 years later, we have pretty much almost the same problem. Okay. In the authentication mechanisms. Okay. Key takeaways. What did I do? That was not intended. It was meant to be a different animation. Okay. So as you've seen, the set of flow does request the user to change their password, but it has two back doors. User, user and guest, guest. For your peeping tongue pleasure when you go to show run and try it out. Seriously. Okay. There we are. Very lame. Seriously. This is not brain surgery. I mean the only thing very sophisticated, if you will, that we did was, you know, find the command execution method. Right? Other than that, passing 200 characters to a password field is really not rocket science. So, yeah. Seriously, check your routers including your AT&T, Verizon, what nots, what have you in your homes. Check them for UPMP. If it's enabled, disable it. UPMP is made so users who like the experience of setting up port forwarding on their own don't have to do that because the devices will do it for them. But you do not want to let your devices do stuff like that on their own because you want to control stuff like port forwarding. Trust me. If you don't believe me, please believe me. At this point it's very difficult to tell how many devices are affected. Unfortunately, as I was saying, our legal department prohibited us from trying all of those devices on the internet. But we hear from reliable sources that they crash just like all the others. We wouldn't know for sure, of course. But that's what we hear. You can, you know, buy this stuff yourself and try it on your own. Or if you're brave enough, you can try it on the internet, on the wild wild internet. So, yeah. Very important for other models, it's the same command execution. It's the same exploit, the same methodology. But you're going to have to go to a different memory address very likely in order to get command execution. Much like this is different from this, the same methodology, different addresses. So you're going to have to basically redo our steps to get the targets for new devices. But it should be very, very easily. I mean, I imagine that the bad guys would be able to do it very easily. And you guys as well. Very important take away. So we need a security certifications for these devices. They're not computers as accessible as laptops or smartphones. They don't provide first hand access to the operating system so you can check them. You have to do just a little bit to spend one or two days to find out what's happening. And obviously, all the average users can check their phones and laptops. No one will check their thermostats or doorbells or whatever. So they will need to find out whether or not that device has some sort of safety feature embedded into it from the store. And I would like to stress the fact that military grade encryption is not security. Anybody agree with me on this one? Yes? Yes? Yes? I know. Yeah. Military grade encryption, which is the crap that I get from all the people that build stuff, you know, ask them so. What do you do about security on this, you know, and an application level, you know, about injection and stuff like that. We use military grade encryption. AES 256. Hmm. Okay. We need to educate or otherwise stimulate. And this is one of the other purposes of this talk. The vendors. To have a proper incident response mechanism. You're going to ask me, did you contact them? Of course I did. I worked for a, not public company, but, you know, a somewhat big company. And again, our legal department would have my skin alive, you know, if I didn't do that. So we did contact them. Repeatedly, they ignored us. We actually contacted another company that OEM, the firmware, and they confirmed it. So different device altogether, but same firmware. The German company did confirm the vulnerability. So I was thinking that there's something that we can do to make them more responsible about this. So we also need to educate the users, right? I don't want to, you know, turn this into a commercial talk, so I'm just going to put it out there. Either from us or from our competition. And I hear that some of our competitors are being hacked as we speak on one of those tables. People will have to get some tools that evaluate the security of their smart house. And ideally, you also defend it. So many people have no idea how many devices they have in their houses. Some of them relate to the things that they bought themselves. But then you have like four devices from ADT or Cox. You have about, you know, four or five other devices from your media streaming service, something that somebody else installed. And it turns out that usually in America, especially, people have about seven, eight, even 10 more devices than they knew in their house. And something that does at the very least the vulnerability assessment on all of those, something that all of you can do, all of you will probably do, but none of the other users will do. Something like that has to be accessible to everybody. And people should know about that. So there are other vulnerabilities discovered in IoT. So this is why the presentation is called IoT, the gift that keeps on giving. You can go, if you want to do a talk at a security conference, go to Best Buy or Target, pick like this, take it home. And I promise you that with a little bit of effort in one week at most, you're going to have a paper. That's how bad the state of things is with IoT security right now. Okay? At this point, it's the low hanging fruit. If you want to speak at conferences, just one week. It's all it's going to take. I promise you. And I would urge you for the safety of everybody to focus on stuff that could be exploited en masse. Okay? So not, it's cool to hack the stuff in your house, but try to focus on stuff that is accessible from the Internet. If somebody would have drawn an alarm for the, you know, myriad of telnet services accessible from the Internet, maybe Mirai would have had a smaller impact if somebody would have, you know, raised that alarm flag back then. So, yeah. So, I guess that's it. I hope you enjoyed it. At this point, thank you.