 how many people here like cleaning their house? No? Oh wow, this is a weird crowd, holy cow. So, um, I don't like cleaning my house. I don't like running a vacuum. I recently had a small child, um, which I thought would be effective. Um, he's now started to crawl. I'm like, yes, human Roomba. But I quickly discovered that the problem is, you can't just put like a, like a, like a cloth or a towel on the bottom of them and have it be like a dust cloth running around because he starts to eat the things and that's, and then it's gonna break the human robot vacuum. So, maybe I will have one of these vacuums in my future or based on what we're about to hear, hmm, probably not. Let's give Fabian and Yisga a big round of applause that came all the way from Germany to talk to you about silly little robot vacuums. Let's give him a round of applause. Welcome to our talk about vacuum cleaners. And it will be about a lot of IoT components including the cloud and the actual hardware. This is Fabian working at ERNW and I'm from the secure mobile networking lab. So, why does it matter? Um, and a vacuum cleaning robot actually has access to your home Wi-Fi and it knows a lot of your personal habits like, um, when are you at home? When are you at work? How many people live in your apartment? How big it is? Do you have cats, children, partners? Um, and my question to you is who of you owns a vacuum cleaning robot? Quite a few. And now maybe some hands going down, who of you have like their own, not owning someone's on the internet, but like really owning your own vacuum robot? Ah, less hands, yeah. Okay, um, so we, um, chose actually the NIDO ecosystem to analyze and, uh, we are from Germany and in Germany, um, these are just, uh, relabeled by Forward and, um, they are selling vacuum cleaners since 1929 or something. Um, and their top model is actually a reprinted NIDO and it always wins the test competitions because it has like rainbow colored LEDs, the NIDO hasn't, and, and a green brush and also a few more sensors, yeah. Um, so we did responsible disclosure and the most, um, urgent, uh, stuff was really fixed in time and also more fixes coming out. Um, no customer data was leaked, but robots were harmed during our experiment story for this. So this is how the lab looked in between doing those experiments. So the infrastructure, um, each, uh, robot has actually a user interface and also some USB console for some basic debugging. Um, then you have a smartphone app which can run some manual robot commands, but these are not for cleaning your house. So this is just a very basic thing going on there. Um, so you actually need to pair it with a user account and the user account is in the beehive cloud. Um, and during setup you set up this account and link it to the robot. And then there is a second cloud, the nuclear cloud, because everything is better with two clouds, obviously. And so the second cloud is somehow connected to the beehive cloud, we don't know how exactly, um, because we cannot sniff there. Um, but, um, it is, the nuclear cloud is then used for, um, for example, starting the cleaning process, getting back a map report, uh, about the cleaning. And there is a lot of security going on there. So the robot itself has like secure boot, encrypted logs, sign firmware updates, so we try flipping big bits and it doesn't work. And then everything else actually has like HTTPS and, uh, special RSA keys between the robot and the cloud and then a secret key between the robot and the user. So really everything is being done there. So you would say like, why did, why do we even give a talk about this? What could go wrong? Um, and I have to say a lot can go wrong, so we managed to bypass the secure boot and extract the image of the robot and our key findings are key findings. And we also did, um, uh, QNAC side quest, uh, and we were able to gain unauthenticated remote code executions on the robots over the cloud. So the secure bypass, uh, actually works that you can put the robot in a test mode, reboot it, and then you would get a special boot loader. And that special boot loader only takes QNX, IFS, so very proprietary thing. But if you manage to compile this, then you can dump all the RAM to the serial port. And, um, if you load it to a special region, then you can read out the original image. And in this image of Nitto, of the robot, um, there's two processes that are very important. The first one is a watch dog called Pinky. And, uh, also Clean and Logic, which is called Brain. So that's why we have this funny subtitle with Pinky and Brain. All right, so I will now talk about the key findings. So first of all, I have to explain what the keys do in particular. So we have the secret key. The secret key is, uh, unique for one robot user account connection. And it's, uh, computed by the robot on first linkage to a user account. And it's used to authenticate commands to the robot. So if you want to start cleaning or anything like that, you have to authenticate this request using the secret key. And the secret key is known by the robots, um, the smart application and also the cloud. And, um, the authentication works with an HTTP header, which is just a basic authorization header in HTTP, um, led by the Nitto app string and then a signature. The signature just takes in the serial number of the robot and the current date of the request and, um, the message body, so the command. And this is then, uh, hashed with, uh, HMEX SHA-256, um, with the secret key as the key component. The second, uh, key that is used in the infrastructure is the RSA key. Um, so we need a second key because the robots have to, at some point, um, exchange the secret key with the cloud for authentication of the commands. So the robots themselves need to have another set of keys to authenticate against the cloud. And also the secret key is not that secret because several parties know it. We know that the smart application has it, therefore the user can extract it and everything. Um, so this RSA key is for authenticating robots against the cloud. And this works similar to the, to the secret key. Um, we have, um, authorization header and HTTP again, um, led by the Nitto bot string and the serial number of the robot, um, followed by a signature. The signature this time is over a little bit more of data. It's the robot serial again, um, the current HTTP method, the URI of the request, um, the current date in the body. And this is then signed with, uh, RSA SHA-256. Okay. So, no. What's, what's going wrong? Um, we have this, um, excerpt of the secret key computation. It's a little bit simplified but I walk, we'll walk you through. Um, so first of all we have this random value that is just a random value. And then we have this, uh, 16 byte timeshift variable. And this is later than used with the SHA-1 hashing. So the secret keys themselves are basically SHA-1 hashes. A little shorter than that but it's the SHA-1 hash. So they look pretty nice and the entropy is really good because we all know SHA-1 is pretty sane. Um, so now it's, um, important to see, um, what the bits in this, uh, and the bytes in this timeshift variable actually are. So the first four bytes are the current time. Well, we know that the time is often used in cryptography. It's not that good but we also have seen worse. So, okay. But then we have some constant values. I don't know why but, okay. So zero is a great number as well as 16. And then we actually use the random numbers. So the, um, byte number eight of the timeshift variable is, um, some computation with a random value. And then we have the next byte which is also some computation with a random value. But this time we, we do some math where we actually lose some entropy because six bit is enough for a byte. So why not? And the last, uh, six bytes then are the robot's MAC address. And, well the robot's MAC address is not exactly secret because the robot's serial number consists of the data production followed by the robot's MAC address. And this one is printed on the packaging of the robot. And, well, on ebay you can see people, uh, doing photographs of the packaging. And then you have the serial number. Uh, also, I mean it's a MAC address so it's a network. It's not that secret. And when the robot is first plugged in it also opens a Wi-Fi access point to, uh, provision it. And this Wi-Fi access point's name also is the robot's MAC address. So, okay. The MAC address doesn't provide any security. The constants obviously don't as well. Um, now the random values. Um, this is not much randomness but it's at least some. But there's another problem because the random generator actually looks like this. Um, this is because they forgot to seed the random number generator. Um, this means if you have a robot that's freshly booted or freshly unpacked, um, it always returns the same random number which there are bias not only a number. And the number we printed here is actually the number that the robot, um, the, the Niatu, um, botweck connected D7s take as the first random number. Um, yeah. So, okay. We don't have any entropy left except for the time now. So the current timestamp. Now the question is how much entropy does the Unix timestamp provide? And therefore we have some numbers for you. So if an attacker knows about one year exact when the robot was first linked to the cloud, that's actually 25 bit of entropy. And if an attacker knows this about one hour exact it's only 12 bit of entropy. And you already see 12 bit of entropy is nothing. You can root for this against the cloud. And, um, there also are some offline attacks against the secret keys because you can sniff some, um, authorization headers and thereby do an offline attack. And with an offline attack 25 bit also is nothing. It's like minutes or even seconds. And, um, yeah. So this is not that secure. You also can think of a, of a, um, social engineering scenario where I just call my victim and say, hey, I'm from the need to customer support, uh, please reconnect your robot to the cloud. And now I know the timestamp exactly. And now I know everything for the secret key computation. And I'm able to actually compute the secret key and send arbitrary commands to the robot. Okay, so much for the secret keys. Now the RSA keys. So, uh, we found, um, them on the robot's file system in slash var slash keys. There's this nice file called vendor private key production. So this sounds pretty promising. Um, it is encrypted at least. But, um, in the binary it's just some string obfuscation. And then we, after some deal obfuscation we had the password. And, um, yeah. So we then figured out that actually the SRK is the same for all robots. Because obviously for a public key infrastructure you want to have the same key on every robot. Why not? Um, this leads to the scenario where an attacker is just able to talk to the cloud and say, hey, by the way, I'm a robot. And the cloud says okay, it's fine. And, um, if you recall the authorization, uh, authentication that, uh, the robots do with the cloud, this was the need to bot string followed by the serial number and the signature. And the only way single robots get identified is this first string which is the serial number. So if I know the private key I can just send arbitrary requests with arbitrary serial numbers in the request. And I can impersonate arbitrary robots. So I can be any robot I want to be. And this is bad. Um, there are a lot of attacks that we can execute on this but I will present maybe yeah, a nice one I think because it's actually we are able to leak the victim's smartphone IP address. Um, because like Iskall mentioned before we have this manual driving mode where we can directly control the robot by pressing some buttons on the smartphone and the robot directly drives like that. Um, and what happens here is that the smartphone asks the nuclear, nuclear cloud what's the robot's network location is. And nuclear cloud then asks us because we are now the robot. Um, what the robot's network location is. Also the robot itself doesn't get any requests anymore because only the last recent robot that locked into the cloud is getting requests. So we can just kick the other robot and we get the requests. And well we then answer with an arbitrary port and IP address combination to the cloud and the cloud then happily forwards this to the smartphone. And well who would have guessed the smartphone just connects to this IP and port. Um, so thereby we obtain the public IP address of the smartphone. We can now do some things like geolocation lookups and know pretty exactly where this person is. Also this opens a channel from the smartphone so if there's any firewall or something like that it's an outgoing connection it's fine. Um, and yeah we, we have a port open and maybe we can do some more stuff with the smartphone even. So this could be a nice attack vector against the smartphone. And yeah I don't think that this should be possible and yeah. All right. So the little Q and X side crest. Uh, as Jiska mentioned the robot is running on Q and X 6.5. And this has some, it's an older system of Q and X. Um so just for those of you who don't know Q and X it's a real time operating system by Blackberry. And um it's actually running in cars, it's running in power plants and some critical applications. Um, but like I mentioned this version is pretty old. There's meanwhile it's some 7.X version and pretty updated and more secure now. Um, but this old version has some nice default settings. So for example R-SLR and DEP are just turned off by default because whoever needs that I don't know. And um, but that's not all. We just stumbled upon something nice when we looked into the robots because um, there's this Prok of S5 system on Q and X. It's just like a normal Prok of S5 system you have on almost every unique system. It's like um, the process memory of arbitrary processes is mapped in the file system so that Root or anyone can read this memory of the processes and also write to it maybe. And um, the problem with these older Q and X versions is that actually the UMask that is set for this um Prok of S5 system per default allows arbitrary users to read arbitrary process memory. So um, it doesn't matter if you are just a normal user or if you are Root you can read any process memory. And this is a real problem if we look into privileged processes like for example the SU binary. The SU binary is used as you might know um, to change the currently um, authorized user with the system. And well therefore it has to check my authentication and this is a password authentication normally. And to get the password authentication right it has to read in the ETC shadow file which is a privileged file and normally isn't readable. Um, and what an attacker can do is he can invoke the SU binary to gain Root privileges and he doesn't know the password but that's not important because he just reads the process memory of the SU process all the time until that very moment where the um, ETC shadow file is read in and he then just has all the information that is written in the ETC shadow file. And well then he can try to correct this and obtain the Root password. This of course isn't limited to the ETC shadow file you can or the SU process. You can do this with any privileged process. You can extract SSL keys of um, processes or just read any data that any privileged process you can execute on the system is able to read. Alright. So um, we looked a bit more into uh, the connection to the cloud and uh, did some fuzzing in the very beginning and um, I discovered a crash lock and decrypted it with one of the locker keys of the image. Um, so actually there is an astro binary and this is uh, connected to the nuclear cloud and then passes commands to the robot binary. And within this astro connection there is a buffer overflow that can be triggered with this URL. And the interesting part here is that um, we found that the buffer overflow is happening when the authentication header is parsed. Which means um, there is no authentication because we are exploiting the authentication itself. So we have an unauthenticated remote code execution on the bin astro. And well luckily we don't even need this QNX side quest because all services run as root. That's very nice. Um, and the fix for this is that by now Nido is um, validating the authentication headers in the cloud so that this is no longer happening. Uh, yeah. So, but it was very nice to just like control any robot if you have the serial ID. Security implications. So if you have an IoT product at home try to keep it offline. This is often not possible so you might use your personal like a second Wi-Fi or something and not the one for the other devices. Um, as a customer you should really update your robot so it's not just um, because security they also have some nice new features um, but also for the security of course. And you saw that the most critical party is the serial number so you need to hide this one so if you have friends visiting hide your robot so that they cannot read it. It's printed on the bottom um, or just put on a tinfoil head or something to help yourself. Um, the second part for the security implement uh, implications here is that for developers it's really important that security is not just done by hitting all the bus routes like oh yeah we have uh, RSA, RNG, hashing, secure boot, encrypted blocks, blah blah blah. Um, but the important part here is that you have a good decision for the root of trust so that you think about what is the trusted components in your IoT network and a very important part here is that dissecting one of your robots should not uh, hide the security of any other component so you should always consider a student having a lot of time dissecting one vacuum cleaner for half a year and then exploiting whatever uh, and you should put a lot of time into uh, testing the, this root of trust so for example this random function if you would have tested it in practice before the hashing then you could have probably seen this uh, in practice that it does not work and just returns the same time always. So um, we still have some time left for Q and A. And thank you for listening. So I don't, it's hard to see people there. Yeah, really no question, no questions, great. Yeah. Down, down here yes, yes what is your question? Ah yeah, so uh the question is if hiding your MAC address versus hiding your serial is a difference. Um, yes it is because uh, the other part um, of the serial is also the production date. I mean it can be guessed but uh, overall it's harder and for the MAC address to know the MAC address you need to be either in the same network for example or you need to be uh, so you have to be physically close for example when you start a robot and it's like making this pairing access point and so on very serious in there. So um, for getting remote control the attack vector gets even larger if someone knows your serial address. Yeah, so for addressing the commands you need to have the full serial number not only the MAC address so you have to get the production date. And well you can try to prove what it, prove what it is but it's pretty hard, it's a lot of entropy. So the serial number itself is more important than the MAC address. Okay, any more questions? Okay, not, not really. Okay, done. Thank you. Oh wait, wait, wait. So one question, yes. Ah, so the question is if they made a more security, key generation method. So the thing is um, we think so but it's hard to confirm because they also fix the secure boot issue. So we can no longer extract the firmware image and confirm if they do proper security. So I mean at least they promised us to do this so I think it is done. But yeah, it's always good to like double check. Yeah, in general they were pretty nice and once we managed to reach them actually because this was a quite long process because uh, we tried to reach them by the customer support but it seems like the customer support just dropped our requests and they never reached the developers. And just like one, like half a year later something we get a message like at 3 a.m. the morning US time. Um, and it was like hey we just saw that you had some requests and we found your plain text proof concept code uh in our tracker system so maybe we should talk. And from then on they were super nice and everything went well. Yeah and I thought like yeah maybe they are in the US and it's 3 a.m. but maybe just call them the same time the next day. Um, and it really was 3 a.m. so the person was like not in another time zone or something. Any more questions? Okay, cool. Thank you. There's another one. Yeah, I didn't see that. Where is the other question? Yeah. So the question was um if there is a specific reason for why in QNX you're able to read as a standard user processes of uh the memory of other processes. So um QNX back till 6.6 I guess was strictly politics compliant and I think this might have to do with it because cause politics compliance means that you really have to um yeah when you have file permissions then you have to really give this permission to any user that tries to read it. Now for QNX 7 and so on the UMask is the same but they also have some other authentication methods in place like more fine granular not only the read bit is set and you can read it. So this might be a problem and also these progress file system is used for some inter process communication and stuff like that. So I think they might have needed this for some features but I'm not entirely sure at this point. Okay. Yeah. So thank you very much.