 I want to introduce a good friend of the village, Jay Balan. He works at Bitdefender. They do a lot of great research. And he's going to expand upon a series of talks he's been doing and research he's been doing about hacking massive exploits across, you know, 500,000 devices. Maybe 450,000. A million devices. Okay, it seems legit. A million devices. Next gen botnets. Sounds cool. Without any other delays that I might be doing right now for people to be sitting down in the back and having a good time. Make sure to speak very loudly and clearly into the mic. And enjoy the talk. Thank you, everyone, for being here. Hello, everyone. Thanks so much for coming to CityStock. My name is Alex Balan, AKA Jay. I work for this nice company called Bitdefender. Probably none of you, most of you have heard of it. And this is the team that kind of put together just this research. We've been doing IoT research as of 2013, I would say. Something like that. This talk is going to be focused on a specific particular topic. And that is leveraging the cloud implementations to get unauthorized access, root access on as many devices as possible. And we've actually focused on cloud implementations or actually bad cloud implementations for a while now. And this is kind of, I've prepared this small montage about what vendors talk about when they receive a report from us. Because we've been sending reports on bad cloud implementations to a number of vendors. And every so often we actually get replies saying, yeah, that's cool stuff. Unfortunately, many times we get no replies. Because that's how responsible disclosure unfortunately works. But just for laughs and gigs, this is kind of what we imagine happens on the vendor side when we send our reports through them. And you see, the sound doesn't work. It worked. Hang on. We hack stuff. Nobody understands the cloud. This microphone, again? Nobody understands the cloud. Yeah, well, pretty much actually that was kind of the vibe that we got from most of the company that we sent our reports to. Essentially, yeah, none of them, or at least most of them don't really understand how to implement cloud for IoT. So with that in mind, I'm just going to stop, start, kind of move into it. So IoT, we kind of see it as this stack of hardware operating system and cloud. So it's an analogy that I like to do. What if I told you that IoT is pretty much like a WordPress website? Can not, just for curiosity, show hands who sees the analogy between IoT and WordPress. Cool, right? I mean, you look at this stack, you have like for those older, as old as I am, you have like hardware, Red Hat 6.2, and Vue FTPD, this FTPD server that was known to provide root access to Red Hat servers back in the, I guess, 1998, 1999, and the likes. Then you had like hardware, Windows operating system, IS 5.0, and the stack goes on, right? So essentially, IoT is like hardware, a busy box environment, mostly Linux or whatever, and then there's an application layer which is, in most parts, like this web app, right? And being a web app is like susceptible to most of the vulnerabilities specific to a web app. But here's the magic thing about it. So you have like this huge threat landscape, huge attack surface because of that web app, right? So you have like command injection, all types of injection like cross-site scripting, all that stuff, right? And then you have another layer added on top of it by the manufacturer for IoT functionality. And they have like this new whole set of binaries stuck inside that IoT that get input from the cloud. And you're going to see what I'm getting with this because the cloud is going to send input to those binaries, these new binaries in that operating system. And you're going to be able to do stuff, cool stuff with it. So essentially, IoTs are just websites running on Linux, but with a significantly bigger attack surface due to mobile apps and cloud. If you want to get into IoT hacking, this is going to be like just a quick crash course and stuff to look for. Obviously, you look for a software. There's still Telnet in 2019, like 6 million Telnet servers open in the internet. Definitely the first thing that you look for is the way the mobile app communicates with the cloud. That's the golden nugget right there. If you look at the way the mobile app communicates with the cloud and start impersonating the mobile app and start fuzzing those requests, you're going to see a number of very interesting things that the cloud replies back to you as you're going to actually see later on. Fun thing, who here is familiar with the flag pie in compilers? Right, so pie is not used in IoT. So essentially, if you get a buffer overflow in a binary on an IoT, you get a shell. You get a command execution. It can connect back shell, actually, because a lot of them are behind NAT these days. So if you get any kind of buffer overflow on an IoT in any binary on an IoT, then you get almost a guaranteed remote command execution on that IoT. And that command is going to be a connect back shell to you, and there you go, boom, shell. The reason why they're not implementing pie, so ASLR is enabled on most operating system running on IoT, but enabling pie for those of you who don't know, stands for Position Independent Executable. It is a flag at compile time, which enables an executable to be moved in memory at random memory addresses in order to not have a predictable memory address to get code execution. So you can just crash it, so ASLR says where you just crash it, you don't get RC, right? But you need to compile your executables with a pie flag in order to allow it to be moved at different memory addresses to be able to benefit from ASLR. Literally, none of the IOTs that we've investigated had any binders compiled with pie. So if you get a buffer overflow, again, full RC, full compromise. Arguably, good old stuff, backdoor, traditional reuse, and look for cloud chatter. If you want to dump the file system of an IoT, the easiest way to do it, and the most popular way to do it, is via serial interface. And for those of you who didn't know, now you know, you can hijack the bootloader of an IoT much like you would hijack the bootloader of your Linux machine. So for those of you who sometimes forget your root password, right? And you pause, grab, and in it equals, BNSH, and all that stuff, well, you can do the same thing with IOTs. And that's kind of the string over there. Just set M, boot args, that's the memory, blah, blah, blah. In it equals BNSH at the end of the bootloader. And you can just pause the bootloader via the serial interface, and bam, you get root access. And from that point onwards, you just plant a small, let's call it a backdoor or whatever you want to call it, to be able to access the system after the next boot, and you dump the file system. Now we come to the cool part, the first cool part of the presentation. Let's look at traditional IoT botnets. The way it used to be done, and the way it's currently being done, we're tracking a lot of them with our honeypots, is they iterate IP addresses, check if they're still not enabled. If they're still not enabled, then they go like brute-forcing tonnet, and maybe they get in. Then they look for web interfaces, and they look for stuff like Netgear exploits, like command injection in the web interface, or stuff like that. And we see a lot of that in our IoT honeypots. There's, I don't know, about a few hundred IoT botnets roaming families, roaming around. Mirai is one of them, so there's probably thousands of IoT botnets right now, based on the code base of different types, like Mirai, Hajime, Hiring Seek, and so on and so forth. Just for trivia, if you're curious what they're doing with those botnets, just out of curiosity, anybody know what they're doing with the IoT botnets? Really? Okay, that guy knows. That's right, it's DDOS. Are you familiar with the concept of stressor services? Right, so those services that you pay to stress, test your infrastructure, or somebody else's infrastructure, right? And you get, like pay, I don't know, like $15 or $35 for a 5,000 zombie botnet to DDOS for half an hour. And for $35, you can take somebody else's website down. We've seen a direct correlation between the functionalities offered by the stressor services, you know, SIM flood, or NTP amplified flood, or DNS amplified flood and all that stuff, and the functionalities extracted from the binaries in our honeypots. So there's a direct correlation between the IoT botnets and the online stressor services. So that's the old way. Now our prediction is that this is going to be the new way. And with that in mind, let me tell you a few things about how cloud is implemented in IoT. Because, you know, direct connection to IoT is like so last Tuesday, you need like port forwarding, and you need direct access to some port on that IoT. So this is why many vendors implemented the cloud. To relay, you know, any commands you would want to give that IoT, or to give you access to that IoT, if it's a video camera, to give you the feed of that IoT, and so on and so forth. And the way it works is that it provides more efficient management, right? Because you have like all these IoT registered to a cloud and the cloud relays commands. It has a modular architecture. So nowadays, vendors integrate each component of that IoT from different types of vendors, right? But personally, I think that's a good thing because maybe they don't know how to do their stuff, and maybe somebody else knows better than them. But that's just me. As far as cloud goes, this is the rough implementation in most cloud platforms. So you've seen at security conferences, we provide an IoT security, you know, an IoT cloud platform. I don't think dozens of companies that provide that. Their architecture is quite similar. You provide, they generate a unique device ID, which is like that. It's a string, usually 32-bit string, that's kind of non-predictable, and that's roughly the bulk of authentication that happens in IoT clouds. If you know that string, that you can interact with the device. Any commands that the application sends are just sent. I want to talk to that device ID, and then some of them actually have decent encryption. We've seen, and thumbs up to the companies that have unique symmetric keys between each app and their cloud, and between each device and their cloud, and that's great. And arguably, this is a genetic description, but it applies to 90% of all the things that we've seen so far. And that's great. Anybody see anything wrong with this implementation? Not so far. However, as it turns out, when you look in depth, not all cloud implementations, you know, are that good. And actually, a thing that we've discovered is many of these third-party modules that IoT vendors integrate in their stuff are good. However, it very often, it's very often the case that it's the way they implement the stuff that's shit. Like so bad. So, for example, Amazon S3. Have you ever heard of bad implementations of Amazon S3? Of course not, right? Yeah, well, MQTT is this new kid on the blog that's actually kind of cool, also poorly implemented by a lot of vendors. So this is kind of what we're going to go and talk about further on in this presentation. So a few words on Amazon S3 buckets. How many of you are familiar with how Amazon S3 works? A few? Cool, cool, cool. So you can correct me because this is me just, you know, babbling on about something so you can correct me if I'm wrong. Thank you. In many cases the bulk of authentication or security that comes with Amazon S3 and I'm talking about the vast majority of implementation is that a device generates a path for a file. So Amazon S3 is used for storage for those of you who didn't know. So the device generates a path for a file and that's the file that I created and then passes on that path to whoever is allowed to read it. That would be the management mobile app of the, you know, IoT device. Now, in most implementations of Amazon S3 you cannot do a listing of your bucket, right? So that's the way it's supposed to be. However, unfortunately in some implementations you can. So just out of curiosity if you're ever doing kind of research on Amazon S3 buckets try to go list my own bucket or even more than that, try to go list the root folder of that vendor and you're gonna be surprised about what you're going to find. So we've seen a really big number of vendors allowing the equivalent of recursively listing the root folder of that company. So not that bucket of that company. So that means all the devices, all the recordings, absolutely everything that's belonging to that company and that's ridiculous. MQTT, essentially you have a device that registered to a server and it registers to something like, you know, vendor device ID slash topic where topic is I'm on, I'm off, I can do this, I can do that, I'm doing this, I'm doing that and so on and so forth. Now, arguably as I was saying earlier one of the major security components of IoT cloud architecture is the device ID. So the way the app communicates is that I've received that I can register to vendor device ID topic and I can read that information. This is MQTT, it's not that complicated. I've learned about it literally three weeks ago. That's when I added, these slides were added very recently. Ideally security counter mergers will prevent attackers from tapping into another device but it gets worse than that. You can actually, when it's poorly implemented you can tap into slash root, much like with the S3 bucket, you can tap into slash vendor and then gets warmed by absolutely all the device IDs and all their statuses belonging to that vendor. And it can be, again, whenever somebody implements MQTT. Again, I'm going to go to a hypothetical scenario here. Purely hypothetical. We want to hack Irene's baby monitor and we want to do a targeted attack. So not just hack everybody but we want to do a targeted attack against a specific person. And what we're going to do is just register to slash vendor, gets warmed with all the device IDs, use the mobile app API to pull the config for each device ID. Because I don't know if you knew this, when you use a mobile app on IIT it refreshes this config from the cloud. It sends, I'm this application for this device, for this customer, give me my config and then it displays it in the settings section of the mobile app. So you can essentially, if you have the device ID you can pull the config, like name, last name, email address, location as one as a fourth for each one of their customers. So when you see the email of Irene popping up you just correlate because you see now that's the device ID corresponding to Irene. So you go to S3 and fetch all her recordings. And of course again for some purposes this is a purely hypothetical scenario. So onwards we've been doing a lot of papers on IIT especially cloud related. edimax is one of them, it's quite relevant because you could get like RCE and you can get a lot of information on that just by knowing the MAC address of the power outlet. And essentially you could just iterate all the MAC addresses, like 16 million of them. We can iterate them over Tor and still get RCE and all that's good stuff. And we come to our start of the day. So as an example of some of the things that I've mentioned before I'm gonna talk to you about this security camera called Garzilla. I think I have a sample here somewhere. So this is one sample. The other one is in my room. And if the demo guys are good with us we're gonna try to hack it. So here's how it works. There's an API at apps.garzilla.com and after the application authenticates you register an account with them you're assigned something called a client ID by us by they call it a UID. But we're gonna call it both but just so you know it's a client ID. Essentially this is a bad implementation for Garzilla and does anybody see anything wrong here? Ours was 408,311. Show of hands who see something wrong here. I mean yeah, it's a goddamn number. I mean the cloud platform did a good job of providing them with like really long string device IDs and they've added a layer on top of that with sequential numbers. So you go like 408,312, 408,313. You can go like a hundred and you're still gonna get somebodies because there's more devices per client. So they wanted to have these three architecture where like client and devices per client. So yeah, the UID cannot be changed. So if you wanted to secure yourself, tough luck. And yeah, it's incremented by one for each account. So essentially there's a username and password actually that's being used in the communication with the cloud. However, they are hard coded in the app and they're the same for all of the apps and all of the devices of all of the Garzillas around the world. So it's cool that they're using a username and password. Well, not that cool that it's the same and it's hard coded. The post requests are actually sent using encryption. AS256 with CDC mode. However, the encryption key and the initialization vector are hard coded in the app as well. So yeah. So what we did, we kind of, and there's also the UID, yeah. So we kind of replicated that and let's see if we can do our first demo. I hope that the fonts are okay. I can make them bigger. Can anybody see? Pretty much, okay. So what we're going to do now is kind of try to pull our data from the Garzilla cloud from a server. This is my VPS in Canada. I usually like to do a lot of remote code executions or not local ARIA network just because that's cooler than local attacks. So I'm gonna use my VPS in Canada which obviously is disconnected. Hang on. Hello. So, BD research, Garzilla. And we have this very small Crip called CMDS which essentially emulates the mobile app. So again, Python, CMDS.py. I'm gonna like get UID from 408.311. And actually, just for beautification, I'm gonna go just because I already know what the output is going to look like. I'm gonna pre-defy just a little bit. HTTP, Grip, that should be equal. And it's a JSON, so JQ it. And there we go. So it's really not that complicated. It's literally emulating the mobile app and I can do that for obviously 312. I can do that for 313. It's up to about 500,000 and something right now. And each one of those people has more than one cameras associated with them. So this is why, you know, Sam was talking about earlier about millions and millions. Well, that's not very far-fetched because if there's like 500,000 users with at least one camera each, you have 500,000 cameras. But more of them, many of them have like two or three of cameras, right? So you get the information that you get is like the device IDs associated with that camera. So this one. And then you get the password set for each. Now mind you, you may want to change that password, but tough luck because I'm going to see it anyway by making this query, right? Because you can change the device password, but it's not gonna matter. So there's a number of functions available in that API. One of them is update user. We're not gonna use that now, but it's just for your information. You can alter the user information like password or email address, and you don't need to use a valid email address to do that. Another one is send invite. And this is a really cool one. It's an API function of Godzilla that allows you to send an invite for somebody to view your camera. The problem is that when you do that, there's no notification for the owner of the camera. So all you gotta do is just call the API and send an invite to yourself, and the owner will have absolutely no idea that you've done that. And we're gonna try to do that now. We have the Godzilla app running on my phone, and do do do do do do do. So I'm inviting that device ID from that client ID, you see? So device ID, client ID, and my email address. And now, oh, look, I have an invite. How cool. So I'm gonna accept the invite, and yeah, yeah, that's my room, and this is the camera live right now. So, see, the seconds are rolling. So this is the camera in my hotel room right now, just for your information, which is kinda cool. Just for fun and games, we kinda developed a new not so orthodox way of getting into the streams, assuming that I'm doing this right. Hang on, hang on. One would argue that I was supposed to boot this way earlier, so I'm gonna get back to it after it finishes booting. So, cancel. Moving on. Again, the owner of the camera is completely unaware that somebody has been invited, not at the moment of the invite, and not after that. So you can send invites to everybody, have a, what do they call it on Facebook, live, watch, invite your friends, stuff like that, yeah. This is how the email looks like, but you don't really need that. And yeah, just for the hell of it, we coded this into gdmi start. Sorry. You see, I have this bad habit of insisting that I do live demos. And, you know, what's life without a little adventure? Live demos tend to break or you miss something. Anyway, until my colleague boots, I promise you next generation botnets, right? So, we dumped the former, we got the binaries, and we ran them through IDA. And, you know, it wasn't very fast until we found the buffer overflow in their cloud agent, which is actually a .exe file. So, they have this Kali platform, again, much like many other cloud platforms, and there's a combination of P2P and Relay servers, and there's main 514.exe that handles the services device side. And upon inspection, we found that a function was vulnerable to an auto bound brides. It's the TK set device model Riku handle. And they specifically crafted buffer. Yeah, I could send. So, this is a code. And we have in the lower right hand corner, we have those two V29 and V28 and V29. All we have to do is just send a buffer that's large enough to overflow them and get past them and then we get, we have like system right after that. And we can call system and we have a command execution, which hopefully we're going to be able to demonstrate. So, let's see. So again, fully remote, we have this netcat listening, and we're going to try to get a root shell in my room. And hopefully, so, this is the almighty exploit. Am I sending it what I'm supposed to send it? Oh, well. Shit, thank you, man. Yeah, actually, that was exactly the problem. And you know, I should have run that in T-Max for screen. Hang on. Yeah, unfortunately, the device tends to crash when you do the buffer overflow, but hopefully, not this time. Yeah. Well, we have movies, as always. So, stuff, demos. So, the movie shows that we get a UID, we get a device ID, and then we just, and we get a shell. I'm sorry that my shell crashed, but yeah, happens to the rest of us. Yeah, and fun story, probably I'm not going to be able to get the video stream either because the device is kind of down. But long story short, you can get a shell, a very predictable shell, works every time, root access, full root access, and all these devices. And there's another vulnerability that we found, a command ejection vulnerability, which is significantly easier to exploit. Essentially, the camera supports something called a remote upgrade. Again, everything relayed through the cloud. And the functions takes two parameters, the firmware version and the download location. Now, the thing is, if you send a bogus download location, it just has to be up so it can initiate a TCP connection to it, it doesn't have to be valid. It's going to pass the rest of the output to, so essentially it's going to do an initial connection to the update location and it's going to pass what you call as the file name to tar, and then that's going to get you a command ejection, a very easy command ejection actually, because tar is going to execute your input and then semi column and then whatever command that you want, and you're going to connect back shell to you. And actually on this device, you can do Netcat, they have Netcat installed, so you can Netcat means E, B and S H to your machine. As a bonus and funny story about responsible disclosure, we were stuck with these guys for about four or five months. They wouldn't answer our emails, so we kind of didn't publish anything because we were like ethical, or our legal department is very ethical. And then somebody published on Reddit the AWS bucket vulnerability that they found. So they're like Godzilla, AWS bucket vulnerability, zero day in Godzilla. And at that point, we were kind of forced to publish our stuff, and we're like, okay, and we have all these other things as well. So we got a call from them saying that they're going to patch their stuff, and they didn't, yeah. I mean, they just patched the AWS thing, they closed the bucket, but it's kind of messed up for them and I understand they're coming from. The whole user ID thing is an architecture thing, and they already have devices in the market. It's kind of hard to change. The buffer overflows, they could patch, but I'm going to bet that I have like this shitty update process, unfortunately, so yeah, it kind of sucks. And then a colleague of mine tells me that, you know, his mother in Puerto Rico has like three of these at home. So yeah. Now, I don't know how we are in, as takeaways, yeah. So IoT is obviously a huge attack surface. I know people ask me, I don't know if what's a good or a bad IoT, what should I buy? And I always tell them, you know, there's a few things that you can look out for. One of them is actually the update process. You know, inherently, everything is vulnerable, right? We're seeing advisories on a weekly basis and all the big stuff, right? Including Google, including us, you know, we get like reports about vulnerabilities in our stuff, not on a weekly basis, but you know, it's very important to look at the way people patch their stuff, how they update, if that update is unattended, if there's any chance that somebody didn't update when the update was available. So that's kind of one of the first things to look out for. The second I would say would be the magnitude of the company or how impacted would they be if a vulnerability was found. Let us not forget, and I hope nobody's gonna be upset with me saying this, that the system is broken, is still broken right now in terms of legal stuff. As a researcher, there's still a challenge in going outside. Remember that hypothetical scenario? It's hypothetical because you cannot go outside of your own space to check up, you know, to see if you can go outside of your S3 bucket or see if you can get outside of your MQTT topic from a legal standpoint. And at the same time, the system is fundamentally broken because D-Link won the lawsuit against FTC. So for those of you who don't know, FTC sued D-Link in February 2015 for MIRAI. And everybody was like, okay, good, you know, people should be accountable for their mess, you know, their strobs. But they lost. In October 2015, FTC lost the lawsuit against D-Link. And it was so obviously they're telling it to enable with one, two, three, four on millions of devices. I mean, anyway. The cloud implementation in many areas is broken, is like fundamentally broken. They're negligent, if not more than negligent. They're trying to add new functionality and we can get that, but not knowing. Do you remember? Do you know the cloud? Fuck! Nobody understands the cloud. So many companies don't really understand how to do cloud implementations for their stuff, right? And yeah, look into that. So vendors need to pen test their products. These guys told me, so the director of product management called me on my cell phone. I was like in Singapore doing some other event. And asked me, why didn't you call us? Well, we tried. Okay, then I asked him, why didn't you pen test your stuff before putting it in the market? And he said, but we did. No. No, we really did. How much did you pay? Seriously. Because seeing that there's a four-way, three-on-one client ID takes five minutes with Burp. I mean, how much did you pay that company to do your security audit before pushing your stuff into the market? Dude, we paid a lot of money. Get out of here, you know? I mean, so yeah. Obviously, Rockback Bounty programs have very good update mechanisms. And again, it's trivial to find RCEs in IOTs. Another more or less honorable mention, and this is a call for me to you guys. How many of you are part of a big company and how many of you are independent researchers? So big company. I feel for you, man. Independent researchers? So you see, because so far we've been able to publish only a fraction of our research. Trust me. And we have this big space with all the things that we've researched, and it's insane. Unfortunately, I cannot talk about it, you know? And yeah. So because it's easier from a legal standpoint if we publish something for companies to go after us and the legal team is like, you know, maybe you shouldn't do that. Yeah, I mean, we already have a lot of other stuff to do. And yeah, maybe it would be best if we just stay on the safe side. You already published some papers, you know? You talked at a few conferences, what do you want, you know? And I'm like, we need people to know about this stuff and patch it and fix it because that's why we do what we do. Yeah, but really? So if you're an independent researcher, if you have the capability, we need more. We need more research on mass hacking IOTs, it's so easy, and we need more of this stuff published. So if you want to get into that, and if you want help from us, yeah, we can definitely help. We will be more than happy to help. I mean, I'm not in Silicon Valley saying that I want to make the world a better place. But I mean, there's so many stuff that's not published and it's so dangerous. I mean, the hypothetical scenario of viewing all the recordings of all the people, of all those cameras from the beginning of time up until today, it may be still happening. And you know, there's a challenge for something like me to talk about it. So with that in mind, I thank you for your time and for your patience. I hope it was enjoyable and yeah.