 I'm Victor Hanna, aka Glyph, for those that know me. I currently work as an IT researcher with a redacted organization. It's really so cool to be speaking at BethCon on behalf of IT village. I can't say just how excited I am to kind of be part of this whole thing. So thank you for having me and taking the time to listen to my talk. I'm going to be taking you through the magic home device takeover and authentication bypass vulnerability that I uncovered late last year, end of 2020 that is. I've entitled this particular package, lid light lunacy, because you know at the end of the day we're kind of all in lockdown and we're going absolutely bonkers and crazy. So it's kind of just a way in which I use to jump out of that whole insane asylum type of scenario and I appreciate you guys being here and let's jump straight in. So the journey to the dead light lunacy started with my attempt to literally blotting up things from my two kids during the extended lockdown period. I decided that I'd look around to see what was available out there on the market. So I purchased an off the shelf lid strip light device that I felt would act as a way to brighten up their day to day as they found themselves you know having to deal with extended periods of indoor life. So why lunacy? Why is it lid light lunacy? Well for me it was because I was kind of getting bored I was kind of being bored since this myself. I was kind of tethering on the edge of going crazy and I needed something to see my teeth into too. So it was basically just an honest attempt to do something around the house. But as I found it turned into a curious case of IT research and I basically decided that I wanted to try and tease out any weaknesses within the device because you know I thought it'd be cool. I thought it'd be something different and a great way to spend my time in the process and eventually it kind of ended up with a verified CV at the end of it based on the inevitable vulnerabilities that I was able to find within this particular device. So what is this product? Well it's simply just a lid light strip as simple as that. So the lid light strip itself and it's designed that the lid light strips themselves have an adhesive backing and they can be adhered to a surface of your choosing. So it'll be at a wall, a door, whatever it might be, a teddy bear. And basically once surface mounted you can control the blinking on and off of the lid light strips themselves. And this is basically just a quick product description that I found that was advertised on the website that I stumbled across. And of course you'll notice the plug and play functionality which is really scary on the onset. So got my hands on the product itself. I went about surface mounting the lids to an appropriate part of their room. They kind of share a room at this point in time so it wasn't hard to kind of... I didn't have to run up between rooms or anything like that. It's essentially their single room that they occupy. Connect the lid strips to basically a 12 volt step down transformer. And then I kind of went through the motions of attempting to surprise them. You know, surprise the kids as to, you know, look what that is done. You've been asking me for a while and voila, here is the product of my hard work. So as you'd expect in the age of instant gratification, the interest was put for really not that long. But nevertheless, I figured I did my good deed of the day. I smiled and then I moved on. So the next item on the agenda was for me was to basically see if I could break these things. Okay, so now to, in order to break the things we need to know how the things actually function. And we need to kind of do that in such a way that we've, you know, documented what available components there are to actually... to use as attack vectors. So attack service mapping, which is what... where I moved on to next was essentially the... It's just a simple way of describing the components that are used within the system and how these components are used to either control or interact with the system itself. So it's basically one of those things that's really initially really useful for security research in order to understand what potential attack vectors exist. And, you know, where you want to... where basically you want to pull your efforts in terms of teasing out weaknesses. So as I could see it, there were basically three kind of avenues to go down, three categories, three technology categories. One of which was IR and kind of messing around with discrete codes and, you know, close proximity to the actual device itself. I kind of considered that one a little less of a priority because I wanted to have kind of a further reach. I wanted to have something that was potentially remotely exploitable. So from this point in time IR was kind of off the agenda. And then obviously had the Wi-Fi which the led light strip controller itself basically tethers to the home Wi-Fi or home or other Wi-Fi segment. And, you know, once you're associated you can actually then start controlling the led lights using the mobile application. So the Wi-Fi and the mobile application became kind of targets of interest and that's where I poured my next efforts in terms of kind of examination and research. And here what I'm illustrating is the attack surface map that I put together. As you can see, you know, the mobile application is running essentially on a mobile handset or handset itself and it's attached to an internal Wi-Fi segment which also the led light strip controller is as well. So that's kind of two points of interconnect there. Once you have the basically registered led strip controller associated with the mobile application, you can then control that over a cloud API. And that gives you that therein lies the kind of remote functionality or the remote methodology in which to control the device from a remote location. So that's that. And so speaking of which, i.e. the mobile application, this is the targeted mobile app that I tested which is Magic Home Pro 1.5.1. That's the one that I kind of was able to use out the vulnerability on. It's basically the mobile app itself is obviously where a lot of heavy lifting is done in terms of functionality around this system. So it made a whole bunch of sense to pour efforts into working out what was under the hood of this particular application. So I moved on to that as a next point call. So in order to do that, I just want to take a little sidestep here just to kind of illustrate basically the tool sets that can be used and typically used on a pen test or an engagement to actually tease out vulnerabilities within mobile applications. We have Frida. Frida is an invadible tool that allows you to hook processes as we all know. It kind of comes in handy when you want to target a process within a particular application. And you can use it for things like SSL pinning bypasses for example, which is kind of most typically where a lot of people would use it. Burp Suite, which shall go without, I mean, its reputation proceeds itself. I think everyone, every man and his dog knows what Burp Suite is all about. But essentially it's a proxy HTTP application that allows you to manipulate transit flows just to see what's kind of happening in terms of the under the hood types of activity. Genymotion is awesome. Genymotion is just an Android emulator, not just an Android emulator. Pretty damn cool Android emulator, but it's kind of cool in the sense that if you don't have a really Android device on hand, you can actually then use Genymotion to run up a whole bunch of sandboxes with the app that you're interested in targeting. And JD GUI, which is what you would do is you would normally take an APK, you convert that to Java and then throw the Java into JD GUI to then have it decompiled into class files. And then at that point you can then tease out functions and classes that you're interested in and work out how they work and then possibly reverse engineer them if you have to. And again, so with all each of these particular applications, tool sets, obviously they're deserving of a talk in and of themselves, but I'll leave it at that for kind of just a precursor to that. So pulled out Genymotion from the toolkit and I threw the APK, the mobile application into the, I pushed it under the device into the virtual device and I started having a look at it through an intermediate proxy to kind of work out what I could see from a chance, from an interesting traffic perspective, some HTTP flows, for example. So I did capture some of those. I did capture the authentication flow and what I noticed upon further analysis was this particular HTTP request, which as you can see basically has inbuilt as one of the parameters, the MAC address of the device that you're interrogating. It also has a couple of other really important, which will be really important later on when it comes time to manipulating this actual application. But those are the binded at unique ID, which is associated with every individual endpoint, the user ID, which is unique to each user as the name implies. The username, which again is unique to each user, and that's there as a part of a kind of a email parameter. And last but not least the token, which is in our case a JSON web token. And that particular JSON web token is please pay special attention to that because that's kind of where we are able to, what we're able to use to manipulate the actual program at some point at a later stage. So using Byrk, I normally go back the emotions of trialing different vectors from a perspective of the web application itself. In this case, after a few other attempts at looking at some things, I landed upon a potential IDOR vector. So an IDOR for those that are unaware is essentially an insecure data object reference. And just means that I'm able to manipulate an object directly outside the application. That's essentially what that means. So what I wanted to do was I wanted to chose the MAC address as my fuzzing target. And so what I wanted to do was take the organizational unit and fuzz for potential serial numbers off the back of that as a suffix to the organizational unit and see what I could tease out in terms of potential MAC addresses that fit within that format. So this is the script that I put together. And this essentially just shows the output of that particular effort. What you'll notice coming back is utilizing my level of authorization, it seems that I'm now able to using the MAC address as the fuzzing target, I'm able to retrieve user unique ID and the binded ID of each of those devices. So what does that mean basically? It just means that I'm able to enumerate every connected device around the world. Which is cool. And that's kind of what I thought I would uncover by doing this. But at the end of the day, what does mean is that potentially two to the 24 devices are affected. And that's really the part that we should be focusing on in terms of based on my level of authorization. I'm now able to see every single device. And that's where it lies, the authorization floor itself. Okay, so if I can do that, what else can I do? That was kind of where I moved on to next. So next I have, I wanted to delve into some of those other JSON parameters that I showed you previously in the previous slide. And based on the fact that it looks like we've got an authorization floor, I wanted to poke around and see what else I could do with the current level of authorization. So at the current level of authorization, which kind of was common sense, I was able to uncover the actual hex data that was used to actually turn on the led lights and the hex data that was used to turn off the led lights. So I knew that that was probably potentially something that I could use. And what I wanted to see was whether or not I could do that not only from my device that I was on control of, but obviously the based on the eye door that we previously looked at, can I do it with a MAC address that's not mine? You know, and basically it turned out that the answer to that question was yes. So I could actually turn on and turn off the lights that were connected around the world. And that was kind of, I thought was kind of cool. So I'm a Python freak. So I put together another Python just to, what we're seeing here is essentially the Python that I put on that illustrates that sending those hex codes does actually turn on and turn off the actual led lights themselves. So this is what this is showing you in the script that I wrote. And so yeah, that's that. So just moving on and delving a little further. Even the fact that we look like that we're kind of dealing with a weak organization, I want to turn my attention back to the data within the JWT and to look into the structure of the payload of the data section. And as it turns out, two of four of the parameters are encoded into the section. And those are the uni ID and the user ID. So what I wanted to try and do was using authorization for, I'm not trying to see if there was a way that I could actually re-sign the JWT with parameters that actually weren't, parameters that weren't actually mine. So what I did was I stumbled across a well-known JWT signature bypass vulnerability that basically allows us to downgrade the JSON web taken to an algorithm of none within the header section of the taken. And basically what that says, what that does is it simply just translates to the ability to now be able to re-sign actually JWT or JSON tokens without the need to re-verify or re-sign the actual signature. So the signature, as you'll see, is an important part of that. So basically, as I said before, I wanted to use the JWT vulnerability to see what we could achieve in terms of our authorization level. But before I do that, I just wanted to discuss basically pulling apart the JWT itself. As you can see, the anatomy of JWT consists of basically three sections. The first section being the header section, which just shows you the algorithm that's being used and the type of token that it actually is. And as in our case, it's the JSON web token itself. But then it also shows the, obviously includes the payload section. And that payload section is a way in which to detail the claim that you're trying to invoke using the JWT itself. It's basically data transmission through the payload section. It's the data part of the actual right token itself. There are different claims that you can make about the payload section. They consist of registered claims, which are basically those that are reserved. So an example of that might be like an issuer claim. So an ISS claim, if you've seen that in the passing, in the travels. There's also a public claim, which is a claim that's created by the developer. And that could be something like a username, for example. So anything that the developer that might want to put into this part of the payload within the actual JWT. And private claims, which are normally kept private between producer and consumer of the token itself. Then you'll notice that the verified signature. So the signature section is essentially just an hmap. And it's as matter of the header, payload, and secret. And it's used basically to verify that the data contained in the JWT is basically verified. So what happens there is each of those sections is based 64 encoded and concatenate together to create the JWT itself. So that just illustrates what a JWT is. And what we're doing, what we're illustrating here is another Python that I put together to actually see if we could forge one based on the actual information that we have. So obviously you can see here, just my email address and my unique ID created a Python that actually forges the JWT for us. And whose output then is a nicely kind of formatted JWT token here that you can see in the HTTP response that will become a little clearer later on in this talk. But essentially, if you look at this, you'll see that the JWT itself is now forged, which is that guy there. Okay. So now that we've got that newly forged JWT, this is just showing us that we can now use that forged JWT to alongside the hex codes that we expected before, which turn on and off the actual led lights. And we can actually turn on and off the led lights. So using the JWT, that's kind of what I wanted to try and achieve in this instance. So it's just using birth to send the request using the forge token. And then the output is the led lights going on and off. So we can turn the led lights on and off. That big deal, right? Okay. So what else can we do? It's something that, as you peel the layers of the onion away, find that there are more and more things that could potentially be used. So one of those operations, one of those things that I wanted to explore using the forge token was actually the sharing of the device with a friend. So I want to work out whether or not we could actually potentially take over the device using this method. And to my surprise, and the answer was yes to that question. So what this is showing is another script that I put together, which takes into consideration the tech is, you know, the targets, you know, the targets MAC address and the forge token. And based on that, we now that the device is under our control, we can now see within the application itself that we have now control of the led lights using our login user. So I thought that was pretty cool. Okay, with all those individual snippets now sewn in into our brain, this kind of slide just shows us the inevitable authentication bypass that the CVE was granted for. And basically what we're doing here is the CVE is allows for an authentication bypass of the mega application itself. And in order to do that, you the, as I mentioned previously, that forge script that I put together is what this particular edit response is. So this flow of traffic we're seeing is essentially the authentication flow. And what we're doing is we're providing the application with a bogus password, which is basically password of nothing. And we are providing it with the user ID that we're trying to take over, which we got from our, you know, previously response we get is this particular thing, which is the account doesn't exist, which means in other words, the password was wrong. And what we do is we with the forge token, we can then edit that response and gain access to the actual application as that user. So essentially bypassing the authentication, in this case, that specifically the password itself. So that that that's kind of cool. And that's inevitably what we set out to achieve was teasing out the weakness within the actual application that would allow us an attacker to take control of the actual led lights. And in this case, we have fully made that happen. So this slide is just showing us the snapshot of the authentication bypass itself. As I was leading to, it's basically the script that I put together that takes into consideration the user account that we want to take over. And the uni ID that we are looking to take over as well, port that stuff into a script. And we get an output, which is the forged JWT and an HTTP response that we require to actually authenticate to bypass the authentication. So this is just showing us that I'm not lying that I can actually take over an account. And it's just showing essentially me trying to log in as a user, as a user that I'm trying to attack. I've given it a bogus password. I've then run my script in the background and edit the HTTP response. And I'm sorry for blurring, but then basically this logs me in as that particular user. I'm just showing you what that looks like from the perspective of an attacker. So what I've got here is what I normally do on any type of engagement is kind of work out what's happening on the ground in terms of network segment that I'm attached to, for example, anything that might be interesting in terms of network traffic that I could potentially target. In this case, I want to be specific about the Magic Home Pro application itself. So I put together basically a sniffer that allows us to intercept any relevant traffic that's specific to the Magic Home Pro application. And all this slide is showing us is the script that I'm using that will essentially utilize Etacap as the man in the middle. It automates both the IP forwarding, sets up Etacap as you'll see here. It then looks like it finds a device, which is this particular device here. And it then adds that device to a loot, which you can then reference later on. So essentially you can have this particular sniffer sitting on a network looking for, if you're that way inclined and you essentially want to attack a little large script, then you can utilize this particular script to enum and harvest a whole bunch of Magic Home Pro devices, but then get added to a loot that you can then take away with you and attack at a later date. So this is basically just showing you that. So what I do now is I go to the attack menu item. It then allows me to punch in the MAC address that we found that was added to the loot, which I'll punch in here. And then at that point, I'm now doing a similar thing to what I was doing before, which is basically taking over the device from the perspective of on off, on off, on off. So that's what you see at that level. Okay, so awkward silence. Now let's move on to the next slide. Okay, so that brings me to my first end of my first ever DEF CON presentation. Huge thank you to both DEF CON and IT Village for allowing me to participate in the event. I really, really appreciate it. Thanks for allowing me to share my content with you all. For those on the ground this year, have a real blast. Bum that I can't be there in person, but I'm hoping to be there next year to share the experience. Please feel free to connect with me on Twitter. Please check out the Spiralabs and Adafire blogs. And last but not least, inspire and be inspired. Thank you to you all.