Transcript
My friends from Team 82, Noam Moshe and Tomer Goldschmidt are here today to talk about a presentation they gave at Black Hat Europe on some vulnerability research into IoT clouds. In this case, they were able to uncover 10 vulnerabilities in Ruiji Network's cloud platform. These vulnerabilities allowed them to remotely execute code on any device connected to the Ruiji cloud. They also developed an attack they call Open Sesame, which allows an attacker in proximity of a Ruiji device to use leaked device information and access the internal network. So this is great stuff, as usual, from Team 82, and I am excited to have them on the podcast to tell you more about it. We also published a research blog that I will link to here in the show notes. Before we get going, just my usual reminder to subscribe to the podcast. It's really the best way to keep up with the latest episodes and the great guests that I have lined up. It's been a super busy year this year, and I think we've done 25 episodes so far. So a really big shout out to all my guests for giving up their time and sharing all this great expertise with you. It's very much appreciated, and thank you all for listening. With some of that said, let's get today's episode started. Hi, guys. How are you? Good to hear from you. Hey, Mike. How are you? It's always a pleasure. Good, Noam. Before we get into the Ruigi research, I just want to talk about, I know Team 82 has spent a lot of time this year researching weaknesses in cloud platforms. I know, Noam, you especially, looking at the exploitable attack surface of the cloud, weaknesses in how devices connect. Bring me inside the research strategy here. Why this approach? What's driving this research? What are you guys seeing? Yeah. It's true. It's true. I think one of the things that we try and focus the most is relevant attack scenario and attack surface for users, organization, all around the world. And currently, I think one of the biggest black spots in most networks that we can see is the unknown IoT devices, because at the end of the day, you buy an IoT device and you are not aware what is going on behind the scenes, under the hood, and what the device actually does. And we see more and more of these IoT devices being connected in some way, shape, or form into the vendor's own cloud infrastructure or cloud platform. And that way, vendors... I mean, the idea behind it is to allow users and vendors to access the device remotely, to be able to monitor it, to be able to maybe do some over-the-air upgrades. However, because of this connection that many times it's not opted, meaning it's by default whenever a device connects, try to reach back to the vendor's sites. Because of that, we have another attack surface that gets introduced to our network. And that way, it takes basically the black box IoT device and adds a whole different section on it, where by attacking vendor-specific services, it could introduce risk and exposure to our secure network. And even if we don't expose the device, because it is not opt-in or it's by default turned on, it could allow attackers to use this attack vector in order to get into our internal networks. And that's why we try and analyze and see and showcase this very, very interesting attack scenario. I mean, it sounds like a lot of the same problems we've been hearing with IoT specifically for, I don't know, five years, 10 years now. So it's both old and new, because yes, we know of the black box IoT device, where you don't know what kind of services it exposes. We don't know what kind of vulnerabilities, hard-coded credentials, secrets in it. And that way, attackers could definitely use this IoT device as a leverage point, as a pivot point, and maybe as part of their exploitation technique. However, this is the old. The new, which once again, it's not new, like a lot of people are starting to notice and do research on, is the way that even if this device is not exposed directly, meaning we do not allow this device to be exposed on the internet and everyone to be able to map it, access it, no matter where they are in the world. Because of this connectivity, this connectivity between the device and different services on the internet, which once again, it's not a way for the device to be exposed. It's not an open port, but instead it's the device that makes the connection to the cloud platform of the vendor. Because of that, we have a lot of inherent risk that is even more substantial than simply an outdated or vulnerable service. Tomer, are you seeing, or both of you can answer this, are you seeing common vulnerabilities or common weaknesses in these IoT clouds? If so, what are they? Are there common configuration problems or vulnerabilities that aren't addressed? Well, there is a certain duality with regards to the platforms. You have this kind of platform or service that is, in both ways, it serves the device and also the consumer that is owning that device. For one side of the research scope, you can see web stuff and vulnerabilities that you may find on a web service or a web platform that provides interconnection to the device for the owner of the device. And on the other side, you can see all sorts of misconfigurations and vulnerabilities that are inherent to the architecture that is used with these kinds of services. So there is a certain duality in regard to the different types of vulnerability. I mean, there is a large scope of vulnerability classes that you can try to find in these areas. And Noam, is there a root cause here to these vulnerabilities? Is it kind of like a rush to market for some of these products, or do the form factors just not support authentication or encryption or whatever it might be? I don't think it's a rush to market, but instead it's more of lack of awareness. And let me explain. You see, I believe that when we're talking about IoT vendors, or almost any vendor out there, the term of user authentication and proper secure user authentication is not a new term. And we see that the community has developed so many tools, so many protocols, so many libraries and stuff to make sure that user authentication, user authorization is secure and basically as secure as it can be. And many times, these IoT companies that do have a problem in their cloud infrastructure, it does not come from the point of view of a user, meaning the user authentication authorization is correct. However, when we're talking about device authentication and device authorization, this is less known and less explored attack surface. Because for a user, you have two factor, you have email, strong passwords, you have JWT, you have all of this infrastructure in place to make sure everything is valid, correct, and good. However, for device credentials, device authentication, this is not as relevant and not as explored. And because of that, we see a lot of times where this exact attack scenario of impersonating a device or using device credentials, maybe badly generated and badly stored device credentials as our point of a start of our attack is very, very common. And I think this is the core issue here and in many different research we've done in the past, where while user authentication is very good, very tight, very authorized and good, the device point of view is less explored. And I think this is only made more serious when we're talking about IoT, OT devices, that by default, the vendor thing is under their control. Because if we're talking about Rigi, the base view of Rigi was that a device is not a rogue device, that it can be trusted. Why? Well, because it's their code, their device, they control it. However, this idea of an attacker impersonating a device, doing something fake on its behalf, sending payloads as a device did not occur to them and was less explored. And because of that, this is what makes this attack surface, this attack scenario of a rogue device, of an attacker gaining access to device credentials and acting as a rogue device, impersonating both the device and the cloud, more and more common and seen today. All right. So that's a good place to kind of just start talking about the new research. And Tomer, maybe if you wanted to start, just kind of tell me, tell the audience a little bit about Rigi as a company, why they were a good research target, and maybe what some of your goals were going in as you started to look at their cloud and the devices. So Rigi is a vendor of network appliances, and they provide solutions for networking in all sorts of settings, commercially available. Also to offices, you may see devices of Rigi maybe lying on a wall-mounted area on an office or at a terminal or, well, maybe you can see it even at households where they're deployed and they provide Wi-Fi access as access points or provide NAT accessibility to LAN networks. So they were a quite interesting target to research on. I mean, they are a company that is fairly popular. Here at Tel Aviv and Israel, we can see those devices like sitting in a lot of places. So it was quite natural for us to start our investigation towards this kind of devices because of their actual relevance to our lives, to their impact, if we would be able to find actual vulnerabilities in. So yeah, I mean, the impact is one critical aspect with regards to picking our target for research. So I guess this was one of the main things that led us to go to that direction of Rigi. And how does, and I want to get into the attacks and the vulnerabilities and so forth, but how does your attack differ from more, let's say, I don't know if this is the right word, but traditional attacks on Wi-Fi and these access points in the cloud, for example? I guess what I'm asking is why go this way versus, you know, going through the web or something like that. Okay. So if I understood you correctly, then when we are talking about, let's say, for instance, a regular device that is on a regular network, we usually take the attack surface that is, as you said and stated, the web service, which is usually exposed to the LAN. But when we are talking about cloud attacks, or more specifically, attacks against IoT devices that are connected and accessible from a remote location, we are actually talking about a chain of vulnerabilities that need to be accomplished, I would say. So it differs with that regard, the difference between a device that is on a local network and you just try to find a vulnerability on an exposed port, for instance, a web service or an FTP server. Well, in our case, when you are targeting a device that is exposed on a local network that you aren't actually in it, then the cloud infrastructure becomes the main bridge between you and the target you're trying to interact with. And actually, to the point of the difference between this kind of attack to other kinds of attack against devices on the cloud platforms, well, I guess the main point of difference is that, or maybe, you know what, the architecture that is used on cloud infrastructure might be different and has some similarities between one another, but every time the architecture is a little bit different. So I guess every time we go and try to take a cloud infrastructure that is related to a device, it's a little bit different. So for instance, here, it was the MQTT PubSub protocol that was used to be able to interact with devices. The interaction between devices and the cloud infrastructure was using a cloud MQTT broker. And yeah, so you may see these kinds of protocols all around the platforms of cloud, but they are mainly deployed in a different way. So it's always refreshing to watch another kind of architecture. And so, Noam, maybe you could take me through some of the risks involved here, because I mean, I'm picturing this as kind of an entry point to a deeper attack, correct? And maybe you could describe kind of what type of attacker would use this technique? Is this an advanced attack or how much pre-existing knowledge do you need to pull this off? So we're talking about a bigger operation attack, because like Tomer told you before, this is not the usual suspect. If we're talking about an IoT device, usually attackers would target internet exposed devices that for some reason whatsoever, it could be misconfiguration, it could be bad security posture, it could be for a legitimate reason. However, for some reason, it is an exposed device that exposes its services into the internet. However, here we are talking about a different attack scenario of attacking devices that are not directly exposed to the internet. And just this fact alone makes this attack more sophisticated than simply searching for a zero day or even a one day on an IoT device, and then exploiting it on whatever is coming up and exposed in the internet using whatever internet searching platform we choose. It could be Shodan, Sensys, whatever. However, here we are talking about attacking devices that are not exposed. And this immediately makes this attack scenario a little bit on a higher level. Yeah, multiple stage operation. Exactly. We are talking about an attacker first researching the platform, the Ruijin REOS of devices. It could be mainly routers and access points. However, the main feature here is that while it does offer some kind of control services like HTTP or SSH, the main selling point here is the cloud connectivity and cloud feature. Allowing sysadmins or whoever manages these devices to control them through the cloud. And because of that, to start this attack, we need to research the device and also go into the cloud infrastructure of Ruijin and find vulnerabilities in these two realms together. So we are talking about a bit of a higher level or cost to entry. So I'd really like it if you both could take me through some of the details of your research from a higher level. Because there's a lot of moving parts, there's a lot of complexity here. You ended up finding 10 vulnerabilities, able to chain some of them to pull off the attack that you developed. Maybe you could kind of just from, like I said, from a high level, go through some of the research. Perfect. So I think the first step in our attack is be able to generate valid device credentials, which is indeed like the first issue or vulnerability in the chain of vulnerability we exploited. We discovered that Ruijin, like many IoT vendors, relied on bad identifier as their security credentials. So in the case of switches or routers, it could be serial numbers and it could be MAC addresses. And by actually being able to generate valid device credentials from knowing something that is not secret, like a device serial number, this is the first issue. Like for example, if you go on the internet or on YouTube and search for Ruijin device unboxing or Ruijin device setup, you'll see dozens of people showcasing their new device. And usually what they'll do is to showcase the actual physical device and they'll flip it over. Usually in IoT devices, on the back of the device, there is always a label telling the user what kind of hardware identifiers this device has, meaning what is the serial number, what is the MAC. Because Ruijin and many other IoT vendors relied on these identifiers, which are not treated as secrets, to validate device credentials, we were able to basically leak and generate valid credentials and connect to Ruijin's MQTT broker that handles all Ruijin cloud platform communication. After that, we exploited another chain of vulnerabilities that allowed us to actually impersonate from a valid device account to impersonate Ruijin's cloud itself. And we were able to send a message on behalf of the cloud. Then all that's left to do is to invoke legitimate functionality that enables Ruijin cloud to manage and control devices, which once again, it's legitimate. This is the main purpose of this cloud platform, to enable users to control their devices from the cloud, no matter where they are in the world. Because we were able to impersonate the cloud, we were able to actually send commands to devices, which basically gave us full control, full RC capabilities on all cloud-enabled devices. And then for me, it resonates with me, the idea where devices and the cloud infrastructure as a whole have this kind of trust relationship that maybe I wouldn't say lacks suspicion, but maybe in some case, there is some kind of trust between the device and the cloud that the other entity is who it's supposed to be. And with Ruijin, this was actually the case where you needed only the serial in order to be effectively taking the identity of the device. So like Noam said, and then you can also do some intricate stuff with regards to the cloud communication with other devices. So the whole relationship between device and cloud infrastructure is actually very prone and very risky turf, I would say. And this really, the idea of this resonates with me. And I think when I'll get my hands to the next research, I guess I will be very suspective and will take it into account when I'm scouring the attack surface with regards to this kind of research. Right. I mean, I don't think it's unusual to see, you know, serial numbers and MAC addresses used as identifiers. Is that correct? I mean, is that done as a convenience? Because it obviously is not a very secure method for device authentication. How do identifiers are not secure? Like if we're talking about MAC address, the... The OUI. Yeah. So the first, the prefix of the MAC physical address is not actually that unique between devices. Yeah. So... Yeah. Exactly. And basically using on this easily guessable, many times leaked identifiers is bad security practice. And yeah, it is a common problem that we see a lot of IoT vendors do. However, it comes again, once again, into the previous statement that actual device authentication that are secure is way harder than user authentication because the device has no email. It has no phone to do OTP. And in some way, shape or form, the vendors still need to validate and authenticate these devices. And I think, Tomer, earlier you mentioned the messaging protocol at play here, MQTT. What was key about finding that protocol and exploiting the weaknesses that you found there? I mean, I think that one of the misconfigurations with the broker or with the protocol that was implemented in ReGIS interface, what was key, in my opinion, was that actually we could, well, you may say, log all the serial numbers out of the interactions between the agents spread all over devices all around the world and the broker of the cloud infrastructure. So this was, I think, a pivot point in our research because we can actually gain access to all of the serial numbers of devices that are spread all around us. So naturally, I think that once you have hold of all of these identifying values that are used to authenticate in front of the cloud infrastructure, you're kind of in a position where you can have a lot of escalation from that point on. And I think another thing that sticks out to me throughout this research, there's a lot of key information leaking in these messages beyond the serial numbers that you guys were able to leverage. Is that correct? Yes. So basically, these messages were able, we and basically everyone in the world with knowledge of this credential generation process was able to leak. In it was a lot of different information because at the end of the day, this connection is made to send events from the devices to the cloud and basically notify the cloud of anything that happens to the device, its status, its network topology, anything. So by just being able to gain access to these messages, this was already a very, very severe security issue. Right. Because through it, you are able to both know and have leak information about basically anything that happens to RAID devices all around the world. However, we could also do the opposite and see what kind of commands and does the Ruiji cloud platform issue to devices, meaning if a user does a backup or configuration changes, these are also sent in a message, in an MQTT message. And because we were able to view these messages due to the misconfiguration, it meant we were now able to see anything that is done in the Ruiji cloud platform. And I think we should say too, before we forget that these vulnerabilities have been addressed by the vendor. And I'm just always curious, how were those interactions? How did that go with the vendor? Because sometimes they're receptive, sometimes they're not. And I know that in this case, they worked through it with you guys. Yeah, exactly. I think immediately when we contact Ruiji with the help of CISA, they were super responsive, super security minded. And I think in regards to actually fixing the issues, it was as fast as possible. I mean, at the end of the day, whenever they got their hands on our report, I mean, the minute they could issue a fix or a patch, it was done. And I think in some vulnerabilities, it even took them a few hours to actually issue and ship the deployment of the patch. So yeah, we worked closely with Ruiji to make sure everything that we reported will be fixed. And they were super responsive, super helpful, super security minded. And yeah, we can happily say that these devices are no longer vulnerable to DevMobile. It felt like they knew what are the implications and the severity of the vulnerabilities we managed to find and their impact. I also want to talk about the second half of this, the proximity attack, which is kind of when you think about attacking Wi-Fi, that's kind of what comes to mind as somebody sitting nearby an access point and sniffing traffic, et cetera. You guys made the point in the presentation and the report that sometimes an attacker just doesn't necessarily want to attack at scale. It can be too noisy or too much of a chance of getting caught. Tell me about the other half of this, the proximity attack, the open Sesame attack. Yeah. So this kind of method, I guess, methodology where an attacker doesn't want to actually do a mass scale attack on all devices and pinpoint the attack against one specific device is actually an attack that could happen with, I guess, specificity of the victim as a target. So it's not just that this attack could happen. It also has a name where a drive-by attack could actually happen and is actually a viable attack scenario. So when we figured that the actual beacons that are sent in broadcast from the device contain the serial number, we were like, okay, so anyone can just happily take these captures of the network beacons and just using these vulnerabilities that I would say that the difficulty of exploitation and the severity and the impact that relates to this exploitation attempt could just infiltrate those networks. So for instance, an attacker could just go near a office building or maybe go in a floor and try to sniff the network and suddenly you've got an attacker lying in your network without even noticing that he sits on the device that provides you with Wi-Fi network access. So this specific scenario that is really, really also interesting and also very scary, I would say. And the risks are pretty similar. I mean, access to the internal network and from there a larger attack, correct? Yeah. I mean, we all use Wi-Fi networks all around us. I mean, I wouldn't like somebody to be on my access point in my home or in my office when I write my documents or my research reports that is, I would say sensitive in some way. Noam, just to go back to the fix for a second, how extensive do you think this fix was? It wasn't necessarily an overhaul of things, correct? So it was both. I mean, at the end of the day, we discovered both like specific pinpoint vulnerabilities in specific sections of code. However, we also discovered bigger architectural flaws. So I would say these fixes that Riju issued are composed of both. Both changing their security posture from an architecture point of view, meaning how do we authenticate, how do we validate connections? And both in like specific pinpoint locations where we discovered security flaws. And at the end of the day, like architecture flaws and architecture changes are taking more time because you need to make sure everything is correct. You need to build everything good. However, both were made. I mean, it's so encouraging to hear that vendors are being responsive because it wasn't that long ago whether when it was, you know, it definitely could have turned into a hassle for the researcher. Yeah. Absolutely. All right, guys. I want to thank you both for coming on the podcast and congratulations on, again, speaking at another Black Hat and for some great research. I know this is a lot of work and to see it pay off like this is a big deal for you guys. So congratulations. Thank you, Mike. All right, guys. Have a great day. Thank you. You too. Bye-bye.
