 Good evening. Today I will be talking about the smart home I didn't ask for. So my name is Neil Samia. I'm a security researcher working at Kudalski Security. And I have interest in privacy, data processing at scale, and I'm a huge Linux fan. So what is this about? Basically, I'm going to tell you my story with a smart home. And first, we'll talk about how I analyze network traffic, then how I analyzed the tablet itself, the findings I discovered, and how I disclosed those findings. So once upon a time, I was looking for a new apartment. And I found one for rent and decided to rent it. And the day I moved into this new apartment, this was on the wall. So it's a wall-mounted tablet that runs an app in kiosk mode. So there is no apparent way to escape that app. And you can use it to control assets inside of the apartment, such as motorized blinds, control the heating, turning on and off the lights. And when someone rings that the doorbell, you can also open the building's main entrance door. And more and more buildings come pre-installed with such smart devices. And they have very deep integration into the house or apartment. And tenants who rent the apartment become dependent on these devices because they really have to use it to do day-to-day tasks. And one example of that is, for example, if you have a balcony and you have blinds that are on the outside of the windows, and if the blinds are down, you cannot get out on the balcony. And the only way to get on the balcony is to turn the blinds up. And you have to use that tablet to turn the blinds up. There's no other way, no manual knob or anything. So this really creates a dependence on the smart device. So this tablet can be used directly, but there is also a feature that lets you pair a smartphone to the tablet. It can be an Android or iOS smartphone. There's an app for that. And when you want to pair it, you click a button on the tablet. It's going to generate a four-digit code. And then you have 60 seconds to enter that very same four-digit code on the smartphone app. And if it's the right code, then it gets paired with the tablet. And once it's paired, you can use it to connect things inside of the apartment from anywhere on the internet. So at that point, I was really skeptical and started to really wonder what the security of the system was like. So this brings us to the first chapter, network traffic analysis. So I had a look at the Android smartphone app. That's called eSmart Live. And I quickly saw that it mostly produces encrypted traffic, so there's not much to be seen in the clear text traffic. So I was like, OK, we can do a man in the middle attack to see what's going on and see the clear text traffic here if there's no special protection. So I used a Pixel 4 smartphone. That's what I had. It was running Android 11. And I routed it with Magisk. Just follow the tutorials. And since Android 7, the apps on Android only trust system-wide certificates. And you cannot install them directly. You have to install user certs first. So what I did is I used an extension that you can install directly from the Magisk app called Move Certificates. And that can be used to move a user cert to a system-wide cert so that then your cert is trusted by the app. So that's what I did. And just analyzing the traffic, so we see that there is very little HTTPS traffic. But the meat of the traffic is using XMPP, which is a chat protocol. So to intercept the HTTP traffic, I used a tool called Meetup Proxy. But we could have used Burbsuite or whatever proxy you'd like to use. And for the XMPP traffic, at first, it looked unencrypted. But quickly, during the connections, the traffic gets encrypted because they send a start to less message. And then the rest of the traffic is encrypted. So we need to also intercept that traffic and do a man in the middle here. And most HTTPS proxies just do HTTPS. They don't do XMPP. So here we needed another tool. And one that worked for me is called XMPP Meetup. And this is what I used for the man in the middle for XMPP. So here we have an example screenshot in Wireshark where we see an XMPP message in the clear. So we could decrypt the traffic. And here it's just the tablet sending us an invitation to a private room on the XMPP server. We'll see why that is used next. And to put that in place, I just set up a software Wi-Fi access point on my laptop that gives us a new network interface, let's say AP0, and then use the routed smartphone to connect to that software AP so that I can intercept and collect and capture the traffic on the laptop. And for the HTTPS proxy, so I just used Meetup proxy, like I said, and just instructed it to save the TLS handshakes to an SSL-Keylock file. And then we can use that file inside Wireshark. Just go to the preferences, browse, choose that file, and it's going to decrypt the traffic for you. And for the XMPP proxy, it's very similar. It's just that apparently the app was checking for the domain name that was in the certificate. So I had to generate one that had the domain name XMPP.mylesmart.net so that it works. And then same thing, we just run the tool, say that we want to save the TLS handshakes to an SSL-Keylock file, and do the same thing with Wireshark. And finally, last thing that was needed is we needed to do some redirecting to some ports and some addresses with IP tables so that the traffic goes in the right direction. So in the end, we could actually see the traffic in the clear. So the app was not doing any certificate pinning. And inside the XMPP messages, JSON payloads were sent. And here we have an example of one of these payloads. So for example, here, when I was on the app, I clicked the button to turn on a light. And it just sends like a payload where the body says turn on asset number 13. And 13 was a light. So I tried also to see to understand what the app was really doing, just seeing if we could decompile the source code of the app and see if it's readable or not, but it was obfuscated. So we could have tried to reverse engineer it, but that may have been a lot of work. And as one famous security researcher who did the keynote yesterday says, if it's smart, it's vulnerable. So there was probably a quicker way around this. So I decided to move on. And this brings us to chapter 2, analysis of the tablet. So the goal was to see how the tablet works. And first, is there a way we can connect to the tablet to analyze it? So it turns out the front pane plate of the tablet can be removed. It's just sticking with magnets. And it reveals there is micro-USB cable there. So if you have the right-angled micro-USB cable that fits in the plastic, you can just connect it to a laptop and see what happens. Maybe we have USB debugging enabled or something like this. And so just for the record, behind the tablet, there was a hole in the wall. And inside that hole, there was a chip. And there's an ethernet cable that goes inside that chip. And this is where the tablet gets its network connection. So using the cable, we immediately see that USB debugging was enabled on the tablet by default. So we could use ADB to connect and see what we can do. And just doing ADB shell, we see that we are roots on the tablet. So these guys are delivering tablets that are routed and have USB debugging enabled by default. And the tablet runs Android 4.4, which is pretty old, I would say. So one of the first things I tried to do was to enumerate what apps were installed on that tablet. So just did ADB shell PMList packages. And we see that here I stripped the output. But there was four apps that had My eSmart in the name. So it looked like these were apps made by the vendor. And there was one app called Quick SSHD that looked like an SSH server that was installed on the tablet. So then using another command, we could get the path where the APK file was located on the tablet. And then pull that APK file and get it on my laptop. So that's what I did. And so the targets that I identified were these four eSmart apps. So there was a tablet app, manager app, OTA app, and a launcher app, and this SSH server, the Quick SSHD. So what I did here, I just used ADEX to unpack and decompile the APKs. And sometimes it could not decompile all of the codes, or some functions sometimes could not be decompiled. But it was good enough for me. One other way would have been to first convert the APK file to a JAR file, for example, with something like nJarify. And then use more classical Java decompilers, such as the one you have built into IntelliJ that's called Fernflower. But I tried that, and it ran for like three hours. And it was still stuck. So JAREX worked better for me. So after decompiling that, I had a look. And the four eSmart apps were actually not obfuscated, so it was really easy to see what happened there. So here we have a screenshot of some part of the code that was inside testing that was inside of the tablet app. And here it's part of the code that is used to unlock the door when someone rings the main building entrance door. In the code, we also see that there are four different versions of the tablet hardware. So the one I had installed in my apartment was the RK3188, but there's mentions of three others, C91, C93, and Finch. And apparently, some versions of the tablet are running a different software or do different stuff. Maybe they have a different UI. It looks like there are at least two versions of it inside. What I also did next is I copied files from the tablet that were in some specific directories that could be interesting, like data, data, and the SD card folders. In data, data, there was a specific directory for each app. And in the tablet app folder, there was this file called doorIP.txt. That contained the IP address of the main building entrance door, so 10.0.5.100, that was for my building. And in the code, like we've seen in the screenshot before here, what it did actually is it just does an HTTP get request to some URL on the door IP, and that just opens the door. So there's no authentication. You just have to be connected to the internal network, and that's it. You can replay the traffic and open the door. So that's what I did. And here's a quick video. So just for the video, I had my laptop plugged to the internal network inside the apartment, had the SSH server running on the laptop, and I connected to that using my smartphone from the outside of the building to open it. And the smartphone was just doing the HTTP request to open the door. And that's it. Just opened the building. So in my neighborhood, there were actually six buildings. And in each building, there was eight apartments. And in each apartment, there is one tablet. And just one building door per building. And then you have the apartment doors, but these are not connected. You have to use a physical key to open those. So all of those tablets and the door are connected to a switch. And then all the switches are interconnected. So basically, the whole neighborhood is connected. So they share the same network. And what I did is I was connected on that network. And looking at the IP address, and I was like, OK, $10.00 and $5.7. I'm in building E, apartment 7. It looks like there's a logic in the naming of the IP addresses. So you could just target a specific tablet or a specific door. You can just guess which one it is, but just by the number in the IP address. So for example, if you want to target the tablet inside building B, apartment 5, it's $10.00 and $2.5. And if you want to target the door of building B, it's $10.00, $2.00, $100. The doors are always $100.00. So I tried to ping the tablets in my building first. That worked. And then I tried to ping stuff in the other buildings, and it also worked. So yeah, it looks like we could open the doors in the whole neighborhood. I didn't do it for legal reasons, but when I reported it to the vendor, they didn't deny. So it looks like it would work. And so just as a reminder, you cannot open the apartment doors, right? It's the main building door. You still need a physical key to get inside the apartment. So this brings us to the findings chapter. So after analyzing the non-obfuscated decompiled source code, this is basically an overview of how the whole system works. So we have an Android smartphone that runs the eSmartLive app. And that smartphone, when you start the app, it's going to connect to an XMPP server and join a public room on that server. And the tablet runs multiple apps. The tablet has the tablet app, which also connects to this XMPP public room on the XMPP server. And when a smartphone tries to link to pair with the tablet, and it puts the right 4-digit code, the 4-digit code is actually sent on the public room. And all the tablets are kind of listening there and trying to see if someone sends a message with the expected 4-digit code. And if that happens, the tablet is going to create a private room, join it, and then invite the smartphone app inside of that private room. And once the tablet and the smartphone are inside of the private room, the tablet is going to interpret all the messages that are sent by the smartphone. And that's how basically the smartphone tells to turn on lights, control stuff inside the apartment. Another thing, there is something called a web platform that is actually used by the manager app. And this app is regularly checking whether there is any commands to be executed from this web platform. And one of those commands is actually instructing the tablet to do a remote port for warding on an SSH server that they call the tunnel server that is hosted by the eSmart vendor. And this is actually used by a technician that works for eSmart when they want to do remote troubleshooting. So it just basically opens a port on the tablet so that the guys can then connect back to the tablet from the tunnel server and diagnose and troubleshoot problems on the tablet remotely. And they can do this because there is an SSH server that is always running on the tablet. So as I said, when we start the smartphone app, it connects to the XMPP server. And both the tablet and the smartphone app have something called a Java ID or a JID that is something used in the XMPP protocol. And this value is derived from some random value and the MAC address of the device. And when authenticating on the XMPP server, the way it works is it uses password-based authentication with SASL and the digest MD5 mechanism. The password is just this JID. And sorry, the username is just this JID. And the password is a hash of this JID concatenated to some random value. And registration appears to be open on this XMPP server. And this is actually what the tablet does when it first runs. So when they deploy a new tablet, it's going to basically generate credentials, generate a JID, a password using the technique described above. And register on the XMPP server and then connect using that the next times. So they both join this public room. And when there is an invite, the tablet creates a private room that is named as its JID and then concatenated with at conference.mysmart.net. And when pairing is successful, it invites the smartphone inside it. And then, as I said, it's going to interpret the messages. So I was wondering, is there a way we could remotely exploit this? Because the room name is just the JID plus some hardcoded strings. So maybe there is a way we can guess the MAC address or maybe just connect to the XMPP server. And since it's open registration, you could just create an account, connect there, and enumerate the devices that are inside of the public room. So I reported this to the vendor. And they said that someone else had already reported it and that they had patched it early 2021. So this was an actual issue in the past. But now the rooms are invite only. So this is just a screenshot. I mentioned the web platform before. When you go to that URL, you will just see a login form. And this platform is smart for sending comments, but also for the agency that owns the building, for example, to send messages to tenants in all the apartments. So I mentioned this tunnel server. And it's actually just a SSH server. And the technician uses to remotely troubleshoot. And the authentication that is used is just password authentication. And it's actually using an MD5 hash of the password that is stored in a text file inside of the tablet. I tried to brute force it, but it looks like it's a very long password. So there's no easy way to brute force it, even if it's MD5. But there is another way that we could go around that. Actually, since the tablet runs the SSH server, and we have access to it. The tablet has USB debugging enabled. We are root on the tablet, so we could modify the SSH server so that it logs all of the login attempts. So you could just dump to a file the password and the username when someone tries to log in. And that someone could be the technician, right? So you could just pick up the phone, call the smart guys, and say, hey, I have a problem with my tablet. Can you remotely troubleshoot it? And you just wait for them to send the remote port forward in command, then connect back to the SSH server and collect the password that's in the log file. And one thing that is also problematic here is that all of the tablets in the same deployment, for example, in the neighborhood, they have the same password. So if you were to do that, you collect the password, then you're on the same network. So you can connect to the other tablets that are in the whole neighborhood, basically, because they all have this SSH server running, have the same password. And these tablets, they have a camera, they have a microphone, so there's like a real privacy issue here. And the tablets are also rooted, so if you get SSH access on your neighbor's tablet, then it's game over. I mean, you can run commands from there, you can turn on off the lights, control your neighbor's apartment, basically. So what way to remediate this would be to not use public authentication, not use password authentication for the SSH server, but use public and private key authentication. So this way, even if we control the server, there is no way to get the private key. And another thing is that this server doesn't need to run at all times. They could just shut it off and turn it on only when it's needed and when they need to troubleshoot. They already have the web platform to trigger the command, so they could do it at that point. And some other findings, so the tablets are all on a separate internet connection, and the owner pays for it. So you could enable a Wi-Fi hotspot on the tablet and get free internet, since I'm not paying for it. You could also spam the pin codes, the four-digit pin codes when you are trying to pair the smartphone with the tablet. So there is no throttling when sending a pin. So you could just try all possible combinations and wait for someone to try to pair a smartphone and I guess you would be connected to a random person's tablet for a while until they figure out that it's not the right device that's connected to their tablet. I guess you would also get detected pretty quickly, but you could still be able to connect. So this brings us to chapter four, disclosure. So just a quick summary of the findings. So USB debugging was enabled by default on the tablet. The tablet is routed. We can open the door of other buildings if we are on the same network. The tablet runs an old version of Android that doesn't get security patches anymore. The apps on the tablet are not obfuscated. There is no certificate pinning on the Android smartphone app. The SSH server on the tablet uses password authentication, so we could collect this password. And there is no rate limiting for the pin code for pairing. So in December last year, I reported all of these to the smart team via email. And they acknowledged receipt the next week. Then the next day, they gave me an official response to all of the items, but I thought it was not really clear because some of the points maybe were not really well explained. So I offered them to meet them in person because they were not too far from where I lived. And we had to wait just a bit because it was almost the holidays. And then in January, I reminded them that I wanted to meet them to explain the impact of the findings. And finally, we settled on a meeting date. And finally, we met mid-February and explained all of the issues. And they said they were going to work on it and prepare some fixes. And finally, in May, I notified them that this talk was accepted and that I was about to publicly disclose it. And I received a response saying that a fix was in progress and that it will be deployed this month if the final tests were successful. And then I had no news. But I checked in like two weeks ago and they had disabled USB debugging. So it's not enabled anymore by default. And the SSH server has been uninstalled from the tablet. So in conclusion, smart devices should be built with security in mind from the start. These devices have really deep integration into the house or the apartment. So it can lead to privacy issues and really bad consequences even if it is hacked or even if the system goes down. Like you could not even go out on the balcony if it's not working and the lights are down. And if you want cool research, just put a smart device in a security researcher's house. So thank you. Do you have any questions? So thanks a lot. We have about two minutes left. And if there are any questions, please ask them. Micro, microphone in the back, please. Hi, a cool talk, by the way. Did you were you able to figure out the protocol that the tablet speaks to your smart house? So you maybe could replace it with something that's not terrible. That's a good question. So I have not looked at what the tablet does when it speaks to the actual assets in the apartment. What I just saw in the code was that it was opening a connection a serial port. And I guess it sends something to the module that was behind the tablet inside of the hole. But I haven't looked at it. OK, Signal Angel, do we have any questions from the internet? No. So microphone on the front, please. Hi, thank you for your talk. You said the tablet had a microphone and a camera. And are there any intended uses for these devices? Yeah, that's a good question. So inside of the apartment, I think the camera makes no sense because when someone rings at the door from the outside, you can see them from inside the apartment, but they cannot see you. So the camera should not be there. And in my apartment, I just put a sticker on it so nobody can see it. But for the microphone, yes, because you can talk to the person that's on the outside when they ring at the door. Yeah. OK, and we are out of time. And I would like to thank you for this very interesting, but quite frightening talk. So one round of applause, please, for Niels.