 Uh, next up we have Smea talking about real penetration testing. Please give him a warm welcome. Alright, uh, hi everyone. Uh, as mentioned, I'm Smea and today I will be talking about how to hack a butt plug. Um, this is one of those, uh, just FYI, I don't know if you ever seen one in person, I had not. Um, but I've been introduced to a lot of things over the past two years so, you know, here we are. Uh, you might be wondering what is like, what does it even mean to hack a butt plug? Because you know, if you take a look at this it's basically just like a piece of silicone. Obviously you're supposed to put it somewhere. Um, there's not much to it, right? You don't really need, uh, any electronics in here. But over the past couple of years, um, or a couple of years, I mean like, past few decades even actually, there's been the emergence of this new field called, uh, teledonics. Um, look at the etymology for this, uh, you know, it's from the Greek tele which means from afar. Uh, and the English dildo which apparently just means dildo. There's no origin. I'd try to look it up. Uh, no one knows where this word came from. Uh, but yeah, it's pretty self-explanatory, right? The idea is that you want to make sex toys that are controllable remotely, uh, in some way. Uh, and it actually, uh, you know, enables a number of different scenarios. Um, basically, I just want to explain to you because not everyone is familiar with this field, okay? Just want to explain how this works. Uh, so you take this butt plug, right? Uh, you insert it. Um, and from there you're, you're actually able to like control it from, uh, from your phone. Uh, your phone from your laptop from any kind of device really. So that's, that's the first scenario. Second scenario is like technically kind of the same thing. So you end up getting control to, you know, someone else. Um, now this is an actual thing. Um, and so they actually advertise this for like, oh, you can like go out to the bar and like no one will know. Uh, it's kind of fun. Uh, but technically it's like the exact same thing. It's just, it opens up, you know, a new kind of attack scenario because you're giving control over to possibly a stranger or, you know, someone else. Uh, which does change the threat model here. Uh, the third scenario is going to be the same thing, you give control over to someone else, but this time it's going to be over the internet. Um, and you know, you can kind of think of that as, it's probably not going to be a stranger, but it might be. Uh, it's going to be enabling, uh, people in long-distance relationships possibly to, to have some fun, which is pretty cool. Um, but, but the real, where the real money is, is actually with using this, uh, as, as a sex worker. And I'm, I'm not trying to make a joke of this, like people actually do rely on these, uh, on these things as, as tools to make a living, right? Um, and in my opinion, this actually is, uh, something that kind of gives some legitimacy to this research because you know, I'm, I'm just hacking blood plugs. Yes, it's funny, but people do actually make a livelihood off of this, right? Uh, it's like some scenarios are going to be, you know, cam girls, cam boys, uh, whatever you want to call them, people who, uh, basically provide dynamic, you know, sex entertainments, uh, over the internet, uh, are getting paid to have people watch them and they sometimes have the ability to, you know, get paid to give control over to their sex way. Um, they, the company that makes this but plug actually has a patent on the concept of tipping money over the internet to control butt plug. Um, which, you know, that's a whole other debate but it's kind of interesting. The, one of the scenarios also is like, you can, you can either, yeah, uh, have it vibrate in exchange for, you know, a five dollar tip or something, but it can also be, you create a link to control your butt plug and you give it out to someone on Twitter or someone on whatever, um, just to give them control for a limited amount of time. Uh, so people actually do, you know, rely on these as tools for their work, so it's kind of important in my opinion to take a look at what the security boss here is here. Uh, and so the security boss here, like, let's think about scenarios that are interesting for, for us in terms of hacking these butt plugs. One of them is just going to be okay, well, you're, you're using this locally and someone is within vicinity notices that you have a butt plug in and tries to hijack that connection. Uh, there's actually already been a bunch of research into this, so if it's not going to be a primary focus here, uh, but it is definitely a scenario that is kind of interesting. Uh, we will note that, you know, doing this might technically be sexual assault, I don't know. Uh, it's problematic, please don't do it, whether it's legal or not, just don't be a dick. Um, second scenario, it's kind of interesting, it's going to be, um, it's going to be looking at doing the exact same thing but remotely, right? Uh, as I mentioned, uh, in some cases, uh, especially if you're making money off of this, you might be giving control over to from, of your sex toy to a complete stranger. Uh, what does that mean? Are they going to be able to, you know, compromise your, your devices or compromise your butt plug or do whatever, do something bad? Uh, so that's a compromise scenario that's totally legit and, uh, and more interesting in my opinion, in my opinion, uh, and kind of what we're going to be focusing on. Uh, and the third compromising scenario, uh, would be the opposite. Uh, thinking about having someone who has a hostile butt plug, basically. Uh, who might be able to hack back into your computer or into your phone or whatever and then possibly hack into whoever is connected on the other end. Uh, which is the other scenario that I don't think people realize this is a real risk of, you know, the hostile butt plugs in this world. So, this is something that we will be exploring. Taking a look in practice, uh, now that we've, you know, introduced a whole world of teledonics, what does it look like in practice? Uh, this is the Levin's hush, uh, which I will be doing a live demo on later on just FYI. Uh, it's built as the world's first teledonic butt plug. Uh, as mentioned, it's a butt plug. Uh, I'm going to just be saying butt plug a lot in this talk just FYI. Um, and you can control it from your phone. It has an iOS app, an Android app. You can control it from your computer. Works on macOS and Windows. Uh, and on Windows you actually do need to use a special USB dongle, which I would show you, but it's probably into my computer right now. Uh, so that dongle has been by a lot of events, so the same company that made these butt plugs, and uh, and yeah, it's like $5 and it's kind of interesting we were going to look into that. Uh, and then, you know, the app actually introduces uh, social features so you can chat, video chat, uh, send pictures and then obviously give control to your butt plug over to someone else. So in terms of the, you know, kind of like a threat map, uh, in my mind. Uh, this is what it looks like if you're thinking about the PC app. Uh, so you have a BLE connection between the butt plug and the uh, dongle, and then the dongle obviously is connected with USB, uh, and so on. Right? Uh, so the question here is what can you, what does it look like for each compromise scenario? Well for the local case is just compromise scenario one. Just want to compromise that BLE connection. Uh, again there's already been research in this. Uh, basically there's no security there. Anyone can, uh, kind of just hijack that connection. There was a great talk last year, uh, about a tool called BTLE Jack which you can just totally, uh, use to take over this. So that's not what we're gonna focus on. Um, the second, uh, kind of uh, uh, scenario for compromise was over the internet so it would be kind of hijacking that connection somewhere or thinking about, uh, seeing how you can compromise one app from the other. And the third scenario, uh, is going to be trying to hack into the butt plug, trying to hack into the dongle, trying to hack into the app, each from one to the other. Uh, and so that actually involves a lot more research. Uh, question is, you know, this is a butt plug. Obviously it's, well, I mean, not obviously, there is actually an open source butt plug project apparently. Um, no, I'm not, I'm making a joke, it's apparently good work. Um, and uh, so the question is, well where do we start, right? I, I started working on this and I was like, well I don't, I don't have the code for a butt plug, I don't have the code for the, the dongle, so what do we do? Well the PC app you can just download it and put it into IDA and see what happens. Um, turns out you actually don't even need to put it into IDA. Because of course it's a multi-platform app, it works on both Windows and macOS, so of course it's an electron app, so of course everything is written in javascripts. I don't love javascripts, uh, but the nice thing about it is that it does end up, uh, still having a bunch of variable names, uh, a bunch of, uh, field names for these objects. Uh, so it is kind of, you know, easy to reverse engineer. Uh, it is obfuscated, but you can just throw into a beautifier and try to figure out how things are going. Um, and uh, and yeah, so once you've done that, you can just kind of like start looking for how the dongle works. Uh, turns out it's just a serial port connection over USB. Um, and, and that allows you to start then sniffing the connection between the dongle and, uh, the app. And one thing that you will notice, uh, the uh, the sniffing, uh, data is on the right here, is that all these messages being set between the dongle and the, and the computer app are all in JSON. Uh, which is kind of interesting because, well JSON is obviously, you know, native for JavaScript apps and stuff, so that's convenient. However, for a USB dongle that is just basically a, you know, 32 bit microcontroller, it's kind of weird to have to embed a JSON parser in there. And for us it's, it's a good thing though because JSON parsers, uh, you know, it's a parser that will probably be bug in there. Turns out there is a bug in there. Um, but it's kind of annoying to, uh, to take a look at that without having the code of the actual dongle. Uh, however, since we do have the code of the app, we can take a look at the update mechanism because they have firmware updates for the USB dongle. From there you can find the URL from which to download that firmware and, uh, download it and see if it's encrypted or signed or anything. Uh, turns out it's none of these things, so you can just grab it, uh, unzip it, uh, throw it into IDA and see what it looks like. Uh, from there we can kind of notice that, yeah, it's, it's thumb code, um, so it's, it's pretty, pretty classic, uh, yeah, uh, arm firmware code. Uh, throw it into IDA, I can kind of see how it looks, start reversing it's nearing. You notice, you notice two things. Um, first thing is it has two command handlers over USB, uh, USB serial. One of them is like these simple commands, uh, such as reset or like asking for device types like that. The other one is basically if it doesn't find a, um, a simple command is going to throw it into a JSON parser which is where we expected, uh, and that's where we can start looking for bugs. One thing that is interesting is, uh, in the process simple commands function is that it does have a command for DFU, uh, so that's the device firmware update. So as expected we do actually have the ability to, uh, to send these commands and get it into, um, uh, firmware update mode. But looking at the JSON parser which is, uh, what we're interested in here, uh, of course we ended up finding a bug. Uh, the bug is in this function called parse JSON string. Um, and, uh, basically that function is just supposed to allocate a new buffer, copy the initial string into the, uh, into that new buffer while also handling things like escape sequences. Um, the problem is, uh, the way that it works is first it, you know, calculates the length of the new buffer that's going to allocate, then allocates it and then does that copy. And so of course there's a mismatch between, uh, the length that it calculates and the length that it's going to, um, actually use at, at the end there. Uh, the way that it works is that it supports, um, you know, the uh, you escape character sequence, uh, which takes five parameters instead of just, you know, zero as, uh, as it expects. Uh, and so because of that we're actually able to kind of escape the, uh, an alternator and make it such that the, uh, string length that was calculated first is, uh, is wrong. This is a little animation here. Uh, what's going on here is that it starts calculating the length, it runs into this escape character, so it skips the character and then it finds the null, uh, null terminator and that's the string, uh, string length that it's calculating. Then in this loop that actually copies into that buffer, what happens is it runs into the escape character, uh, sequence. So it says, okay, there's a backslash, there's a U, that means that I need to skip six characters. And so it's actually skipping over the, uh, null terminator, which is, uh, a problem. And then it just kind of keeps going and it's going to be copying all these characters into that buffer, which is only six bytes in length. So obviously there's a problem, we can, uh, overflow out of the, out of this buffer and, uh, kind of just get code accession that way. This is great, uh, we do have this bug at this point, we don't actually know, uh, what the hardware is running, we don't know, you know, if it has depth or anything like that. Which, uh, kind of complicates, um, exploitation. So we do know there's no ASLR, there's no stack or keys, so it's basically hacking like 1999. Assuming there's no depth, which is pretty cool. Uh, turns out the SOC is just a Nordic Semiconductor SOC, uh, very classic, uh, SOC using a bunch of, uh, BLEIOT devices. Uh, the nice thing is they also left us a bunch of debugging pads, so we can just connect to it, solder a couple things, and all of a sudden we can just debug this, um, this dongle, which is pretty great. Being able to debug the dongle, we can kind of dump the contents of the heap, see what's there. Turns out the heap is only used for the, uh, JSON allocators, uh, JSON parsers, so that's not super great, but it does also include, uh, metadata. So what you're going to see here is that, uh, for each allocation you have a length field, as well as a, um, as a next pointer for the free list, assuming the allocation has been freed. Uh, so the easy thing here is that, yes, we can use our overflow to corrupt a length field, uh, put it to be zero. That way, um, and then corrupt the, uh, the next pointer field. That way the next allocation, assuming the pointer field points to, uh, a non-zero or like a big enough value, uh, will be, you know, placed there. Uh, and since we can place the allocation there, and then, uh, copy a new string into it, it's very easy for us to, um, to use this to basically write arbitrary data in an arbitrary location. We can do this, we'll have a debugger, uh, connected, and as you can see on the right here, um, we, we have the stack basically is being dumped and the stack has been completely overwritten with just eight characters, uh, that gives us code execution on the USB dongle, and uh, that's pretty cool. Um, from there, uh, we unfortunately remember that there was a DFU mode on the dongle all along, uh, and the DFU mode, you know, I would expect coming from a video game hacking, uh, background, I expected the DFU, like the device firmware update mode to just kinda, you know, authenticate the update in any possible way. Turns out, it kinda does with a CRC16, uh, which if you know anything about crypto is not any kind of authentication, I don't think that they actually wanted to have authentication there, it just kinda figured that, well, who cares about getting, you know, code execution on the USB buttplugged dongle, uh, turns out I do. Uh, so that's unfortunate. Uh, but it is, it is, uh, interesting at this point, basically we have two different ways of getting code execution on this dongle, uh, and the JSON parser way, you know, that I mentioned, I spent a lot of time on it, might not seem very useful because we have the device firmware update mode, but it turns out it's actually going to come up again later with, uh, with another vulnerability that we're going to chain together, so, you know, I didn't just say all that for nothing. The point is, we can get code execution, uh, we can flash on firmware, which is pretty great, so at this point we have, uh, compromised USB dongle from the PC app, which is like, yay, that was definitely the easiest part, um, from here. What we want to do, since we have control of the dongle in theory, we should, uh, be able, well, we, we want to like figure out a way to somehow get code execution on the buttplugged because, you know, that's kinda what we do. Um, looking at the hardware on the buttplug, uh, turns out that, you know, there was a debugger on the dongle, so it might make sense to take a look at it. Uh, it's a very similar sock, uh, so it's another Nordic semiconductor sock, uh, it's a little beefier, it's an M4 instead of an MM0, it has more flash, has more RAMs, pretty great. Um, but it is the same technology basically, uh, just more up to date. Um, so the, the nice thing is, yeah, we can't, we can expect that there won't be any depth, there won't be any like, more advanced mitigations on, on the dongle, so it's pretty easy. And there's a bunch of other things that we're not on the, uh, the USB dongle board, but there are a few things that were, which is the SWD, uh, test points, so with that we can actually debug a buttplug. And this is what it looks like in practice, uh, I'm kinda terrible at soldering, but I do have a bunch of buttplugs like this that are opened, uh, in my bag, um, uh, so, you know, I don't know what I'm telling you this, but this is pretty cool. Uh, from there, uh, the nice thing about being able to debug a buttplug is that you can actually use this to dump the firmware. Uh, and from there, you know, kinda figured that if the dongle update mode was so insecure, um, maybe the, you know, maybe the buttplug also had an update mode, which is also super insecure. Uh, it turns out that yes it does, if you send in the same, the exact same DFU command that you send to the dongle, it will also go into device firmware update mode. And from there, there's actually an app that Nordic ships, which is the NRF toolkit app, uh, or toolbox app, and we'll just let you flash the new firmware to it. Um, at this point we don't actually know the DFU mode is, uh, as insecure as on the dongle. Uh, it could have been that they implemented, uh, you know, asymmetrical keys, uh, to, uh, to kind of, uh, authenticate the firmware. Of course, fortunately for us, they didn't. Uh, so you can just kinda dump the, the buttplug firmware from, uh, from SWD, modify it, compute the new CRC16, send it over, and this way you can see on the right here is, uh, you have wire shark, um, a little wire shark, um, uh, trace here that kinda just see, uh, has, uh, the, uh, the buttplug sending back, uh, a little message saying hello from plug, uh, which means that yes, we, obviously we just got correct solution on the buttplug. By not even doing anything, there's no vulnerability here, it's just, it's just kinda by design, you can, uh, reflash it, which might be Loven's attempt to like, open up to the open source community, it's possible, it's unlikely. But the point is, anyone who can connect to your buttplug at this point can get correct solution on it. Um, which seems kinda dangerous. At this point, we do still require, uh, being local, like being in the, the, uh, physical vicinity of the buttplug to get correct solution on it. So it's probably not as big a deal as, uh, as we want it to be, but it's still a good question of being like, okay, we have correct solution on the buttplug, what can we do with this? Well, there's a few ideas that I had. The first one is if you can get correct solution on the buttplug, you can actually create buttplug ransomware. Um, you know, modify that firmware, you make it such that the DFU mode can't be enabled until, uh, you give it a certain key or something, and then you, you know, you just disable all the code that creates vibrations. And yeah, you have your own ransomware, you can ask maybe for like 50 bucks to unlock it, and protect it from future buttplug ransomware. Uh, kind of buttplug vaccine if you will. Uh, so this is a one scenario that could work. Another scenario that is kind of interesting, but I did not really look into that much, is the idea of like weaponizing a buttplug or any other sex story like, uh, physically. Um, and you know, in the case of the buttplug, it really just has one motor and, uh, a little battery. Well, like a pretty big battery actually, like, I guess probably 80% of the buttplug is a battery. So the question is, you know, I don't know if you remember, like, what happened with all these, uh, Samsung Galaxy Note phones, they were like just kind of blowing up. Well, it, it might, you know, possibly be possible to, you know. Again, I'm not an electrical engineer, I don't know if this is actually possible, it probably isn't, but if it was, this would be bad. Um, so you know, I'm gonna assume that this is not possible, but it's something that is worth thinking about, because you do have actually a lot of other sex toys that have other, um, other things in a motor, right? Uh, you have sex toys that apparently have, I was looking at the code of the app, uh, and uh, looking at all the different commands that work for different sex toys. There's a command that says, that just says rotate. So clearly there's some kind of moving part in this, uh, sex toy. Uh, and I'm wondering, you know, maybe, maybe there's like a safety feature for that motor that is actually encoded in the software, right? Instead of in the hardware. So getting code execution on it could have, uh, bad consequences. Same thing, I think there's like another sex toy that has some kind of, uh, air pump, uh, which seems dangerous, but I don't actually know if it could be, uh, problematic. So it's something that's worth looking into. And finally we do have our last thing, which is the hostile butt plug. Hostile in terms not of, you know, exploding your butt, but as much as, uh, kind of trying to hack into your other devices. Uh, so that is something that's worth thinking about, and that's what we're gonna be looking into. It's like, okay, we have code execution on this, we know we can do hand ransomware, but can we start hacking other devices from our butt plug? Of course the answer is gonna be yes, but for now I'm gonna pretend that we don't know that. So, uh, interestingly, uh, well, at this point, we have code execution on a butt plug, we have to figure out if we can get code execution in the app from that butt plug. So doing that is as simple as trying to look into the, uh, the wave of the app kind of handles incoming messages, right? Uh, so the first thing, so this is like a callback on the left, uh, in JavaScript. Uh, I guess this is how it works to talk over, uh, serial ports in, uh, an electron app. Uh, and what it does is it gets N. N is like the incoming data, uh, throws it into, uh, well, it, it casts it to a string and then it throws it to a bunch of different functions. The first function is find dongle, which basically just handles, uh, one of the initialization messages that comes from the dongle. Uh, the second one is on data, so this is like the actual main, uh, command, uh, response, uh, handling loop, uh, handling function, uh, and what it does is, yeah, it takes this incoming JSON blob, uh, which can only be up to 32 characters in length, uh, by the way, uh, I'm not sure why I didn't mention that earlier, it's kind of come up in just a few minutes. Um, so it's just going to parse that and it's going to then use it to do whatever. Uh, it doesn't actually do a lot of processing on this, uh, on this, it's just going, basically going to like stir compare it to something, be like, oh, what's your status? Like what's your, um, how, what's your battery, uh, life and stuff like that. Uh, and the last function that it calls into is actually much more interesting for us. Uh, it's, surprisingly it's much more interesting. It's, uh, I called it debug log, it doesn't really have a name in the actual code, but what it does is it logs the, uh, whatever's incoming, like the serial data, it throws it to the console error, um, function, uh, so it prints it out to, uh, to the console as a, as an error message for some reason, but what it also does is it creates a new DOM element, like an HTML element, and it throws the entire contents that it just received over serial into that element as HTML. Uh, now I'm not a web dev, but if you are, you will probably think that this is a massive, uh, cross-site scripting vulnerability from a Bud Plug dongle. Uh, so from there, basically if you have control of the dongle and you can send anything over a serial, you can actually get the electron app to interpret that anything as being HTML. Uh, that's problematic because HTML, uh, will have the ability to spawn, uh, new JavaScript code and new JavaScript code and, and electron app, uh, basically it's just, yeah, you just compromise the, the computer because there's no sandboxing or anything. So the question is, can we actually do that with our limitation of having only three or two characters at a time? Uh, turns out yes, absolutely, we can absolutely do that. One of the, uh, ways of doing it is what I was showing on the, on the right of there. Uh, you have an, uh, an image, uh, tag with a source that doesn't exist, and then you have the unerror callback which is going to be called whenever the, uh, whenever it can't actually be loaded. And so the screenshot is showing that plugging in this malicious dongle is going to allow you to, uh, execute JavaScript code in the app. So that's problematic. Uh, it's kind of annoying to get a huge payload just because of, um, or the fact that we can only do three or two characters at a time is entirely possible. So at this point we've actually compromised the app from the USB dongle. So we were halfway there to kind of make it back to, from, from our bug plug to the app which is pretty cool. Um, now of course the question is, uh, because you know, what the dongle does essentially is just act as a little bridge between the dongle, uh, between the bug plug and the app. Uh, the question is whether we can just do, use the exact same vulnerability to, uh, compromise the, uh, the app from the bug plug directly. Unfortunately the answer to that is no. And the reason is that we have another, uh, character length limitation on the messages that are coming from, uh, from the bug plug to the, uh, to, to the app. The way it does, uh, does this is on the right you have this code that is in the, uh, that is in the, uh, the dongle, uh, dongle firmware. What it does is it just grabs incoming data. If it sees that it's more than 20 characters it just kind of cuts it there and copies it into the new buffer. Now a new buffer is actually on the stack. And, uh, one of the, there's actually vulnerability there which is that they don't, uh, null terminate the, the, that string. So if you're able to place some uninitialized data after the string you can actually send more 20 characters up to the, up to the app. Unfortunately I do not find a way to actually exploit this but it is a, it is kind of vulnerability so it's, it's worth keeping in mind. So, uh, the problem here is yeah we can't actually use this to get code execution directly on the app from the butt plug which is kind of sad. But, uh, well it's kind of sad for one thing. Uh, what's also kind of sad is that if you took a look at that code there it basically doesn't really do anything with the input. It literally just copy-pastes it into a new string and sends that new string up. So we can't really find any, any kind of, um, of uh, you know, um, memory corruption vulnerabilities in the actual butt plug specific code. However, uh, the one thing that's pretty cool is that there's way more code on this microcontroller than just a butt plug specific code that was written by 11s. There's also this whole, uh, soft device region which is at the bottom of memory. It's, uh, it's based at zero. Uh, and so what this soft device is, it's basically a driver for that sock that was written by, uh, Nordic semiconductors themselves. And so it's going to contain everything that you need to interface with the hardware without having to rewrite everything yourself. And so that's going to include the BLE stack. Uh, so all the code that is going to handle the Bluetooth low-energy protocol. Uh, and so it might be possible for us to take a look at that kind of reverse engineer it because obviously it's not open source and, uh, find a vulnerability in the Bluetooth L, uh, Bluetooth low-energy stack. That's just what we did, uh, in order to hack a butt plug, we were finding Bluetooth vulnerabilities. Um, and, uh, and yeah, so, so because we, we can kind of debug it, um, debug that butt plug or, or the, the dongle firmware, it's actually really easy to kind of just like follow, uh, the flow of data because there's also no ASLR and then it's really easy to define the code that is going to be handling those messages. Uh, and on the right here we actually have one of those functions that handles these incoming messages, um, for the, uh, general attribute protocol, um, for, for central mode, uh, messages I guess. Um, and so, uh, what, what I'm showing specifically is actually, uh, the, uh, handler for, um, for one of the, uh, very, uh, one of the specific commands in the, that protocol which is, uh, the read by type, uh, command, uh, which as I understand it because I'm not really a Bluetooth expert, uh, it's something that is going to allow you to kind of request, uh, reading, uh, attribute, handle, um, you know, data pairs back from, uh, back from, uh, back from the device. So essentially you, you ask read by type to your peripheral device, uh, giving it a certain type and it's going to return all the handles for all, all the attribute services that are, you know, um, associated with that type. Uh, so that, what that means is that it's possible for it to, uh, actually receive more than one attribute at a time and the size of each attribute, uh, a handle attribute data pair is encoded as a field inside of the packet. That means that we can actually control it. Now if you look at the code, uh, what it was doing in that, um, what it was doing in that function is that it has allocated on the stack a, uh, fixed length buffer, uh, for the, uh, attribute data and that fixed length buffer is going to, uh, be struck basically that has just the handle value and then a pointer to the data associated with that handle. So that's what you can kind of see with these, uh, little arrows there is that, can I show you? Uh, oops, if you, you have these little arrows there is that you, you're going to have in, at the bottom left there, uh, that's the actual binary like, uh, hex data that is inside of that buffer. And so you have the, uh, the, uh, 0xd handle and then a pointer that points to that data, like the data in blue that is associated with it. And there's the same thing for the, uh, second handle and third handle and because, uh, it's on the stack, um, no actually never mind, that's not a sentence that needs to be said. So, vulnerability here, uh, if you read the code a little bit, what you're going to see is, uh, yeah, it reads that little, uh, purple field, uh, length field from the, uh, from the incoming message. So that's completely controlled by a potential attacker and if we look at what happens if we place, uh, value 0 there, basically you end up with an unbounded, uh, infant loop. Uh, so that loop is, sorry, because it's unbounded, it doesn't actually check that the, the data that's running into the alpha buffer is within the alpha buffer, we have a very, uh, classic, uh, stack smash kind of vulnerability, which obviously is very unfortunate because on these devices, once you can smash the stack because there's no stacker keys or, you know, ASLR or DEP or anything, you basically immediately have code extrusion. In this case the problem is, uh, because you have, uh, value 0 there, uh, in this specific case it's actually going to be in completely infinite loop, so you're just going to overwrite all the data in RAM with garbage, uh, which is kind of unfortunate because that's definitely going to crash and not going to be useful. But if you think about using value 1, it actually is going to be bounded by the number of bytes that are inside of the incoming message. And what that means is that you're going to be able to, uh, overflow ever so slightly from that buffer and, uh, then from there, uh, because the stack, uh, buff, uh, buffer that is based on the stack, you're going to be able to corrupt everything that's near it. So taking a look at before, uh, what, what happens when you do actually use this, uh, overflow on the stack in yellow is going to be the attribute buffer that I was mentioning. Then in blue is going to be a bunch of saved registers and, uh, orange is actually the return address. So that's kind of the things that you would want to be, uh, corrupting on the stack. And then you run this, um, run the vulnerability. It's going to overwrite all this data on the stack with, uh, in this case completely, well, it's going to write two things, right? It's going to write the handle data, which is actually only overwriting the, the lower, the, the less significant bytes of, of, um, of d words every, uh, eight bytes. And then it's going to be writing a bunch of pointers to data that we control. So this is actually a pretty useful primitive for us. We can just kind of start corrupting everything. We can corrupt the return address with a pointer that points inside of our packets. Uh, and that's really great because, uh, basically that means that as soon as the function is going to return, it's going to execute code that is, you know, placed inside of our packet. Uh, so it's basically, it's basically a backdoor packet if you think about it. It's going to just execute a piece of code you give it without really doing a lot of fuss, which, which is pretty cool. Um, thing is, uh, you know, the QuartX, QuartX M0 CPU actually does not support ARM mode. So we do have an alignment, um, uh, requirement on that return address. It has to be, uh, you know, aligned to two plus one, basically. Uh, so that is one problem because if you look in this specific case, what was overwritten on the, uh, the stack is actually not aligned to that boundary. So this would actually crash, uh, which is not great. There's another, uh, requirement that we have, which is that there are saved, uh, registers that are like actually, uh, like local variables that we're overwriting on the way over that are used on the return path of this function. Uh, one of them specifically is actually, uh, used to be dereferenced at a 32 bit binary, uh, boundary. Uh, and so what happens is, uh, if it's not actually, uh, aligned, it's just going to crash. So that's another thing that we have to take into account and basically, that means that we, we're going to have to slide this, uh, packet over in the way that it's allocated if we want to have any hope of it actually being exploitable. Fortunately, that's really easy because the way that, uh, the, uh, soft device allocates these incoming packets is in some kind of ring buffer with absolutely no, um, uh, enforcement of any kind of alignment, uh, requirements. Uh, and so what that means is that if I send a packet at a certain length before or after, I can control the alignment of this packet that I'm going to be sending afterwards. So this is what we're kind of seeing in, in yellow and in blue are two packets then being sent before the, uh, exploit packet and sent. And that, that allows me to control the alignment of that last packet and make it such that it is, uh, correctly, uh, aligned and not crashy, which is what we want. From there, the way that you actually exploit this to get code execution in the way that's useful and not just, you know, uh, exploiting, well, not just executing two, um, uh, two instructions and then returning is that I send the first packet which is going to contain a bunch of shell code. Then I send, um, another, uh, packet that's going to contain a bunch of data. Another packet that's going to be containing a lot of data. Uh, both of these are going to be used by the shell code. And then a third packet which is going to be the one that actually triggers the vulnerability. Uh, the way that it works is that the one that triggers the vulnerability is going to exploit, execute a single instruction, which is what you see that C1, uh, E7 instruction there. Uh, what that does is it jumps back into the green, uh, allocation into the green packet. Uh, and then that one is going to execute this very simple piece of code which is still, it loads a bunch of registers from the, uh, I think it's a blue packet and then it's going to, uh, use that to call into a function, return cleanly and then we can just send that packet over again. So that allows me to basically by sending four packets, execute any arbitrary tiny piece of code within that, um, within that, uh, remote dongle and then return and, you know, do that over and over again. Which is very convenient because that way I can actually just call into mem copy and, uh, over and over and do that to copy a larger shellcode binary and then we're going to jump into it and that allows us to execute, uh, a lot more code. So at this point we actually just have completely compromised this, we just need to write this shellcode and so because we want our compromise to be, um, permanent, basically we're just going to write a little piece of shellcode that's going to overwrite piece of flash, uh, let us hook, hook into the, uh, original dongle code and, uh, start sending, uh, you know, the serial data that we were talking about earlier. So this way it looks like, um, at this point, if we have control over, uh, an app, we can control, uh, the dongle and the butt plug. If we have control over a butt plug, we can control the dongle and the app and so on. Uh, so we've actually completely compromised the, uh, the local scenario in the case of the PC app. And it's especially cool because this last vulnerability that I just described actually is absolutely not specific to any of these, uh, butt plugs. It's, uh, for anything that uses a soft device, uh, on, on that sock, uh, which is basically everything that uses that sock. And apparently there are a lot of devices that use this old, uh, NRF, uh, 51822. So we have essentially found a vulnerability that could also be used to compromise everyone of those, of those devices, assuming that it's configured in, uh, in a proper way. Or like a way that is, you know, conducive to exploiting this vulnerability. So, uh, that's kind of cool. Uh, finding vulnerabilities potentially, you know, in like maybe smart locks or something like that just by hacking a butt plug, seems kind of worth it and surprising. Uh, but it is, this is a world we do live in at this point. So, question is, uh, we have the ability to compromise an app from the butt plug. What can we do with that? Uh, well, this is, um, you know, we're still just executing JavaScript inside of, uh, the Leven's, uh, Electron app. The question is, what does that give us, uh, because it's Leven's and that this is running at, uh, media mile on Windows. It turns out it actually just gives us kind of everything. We can access all the, all the files on the, on the file, on the computer. We can execute arbitrary code, uh, just spawn, uh, NEXC, uh, that we want. Um, so we've basically kind of compromised the, the computer just by, uh, by doing this. Uh, which is, you know, kind of great, uh, and, and, and helpful for us. Uh, but the question is from there, uh, even if we can create this ransomware that doesn't just infect the butt plug, but also infects the host computer, uh, can we actually make this go kind of viral, right? Because technically we can already compromise the butt plug from a different butt plug or from a different, uh, uh, you know, dongle. And that could be something that we could be used like, you know, uh, kind of spread this locally. But it would be better if we could spread it over the internet because, you know, obviously there would be, uh, much more people that you can reach. Now the question is, uh, how do we do that? Well, there are a lot of these, uh, social features in the app, uh, such as the chat-based, uh, stuff. And the fact that you can just kind of remotely control a toy. Um, so the question is, how does that interface work? Uh, does that allow us to kind of compromise a remote device? Of course the answer is going to be yes, but how does it work? Uh, basically, uh, well that's, that's what I was showing at the, at the bottom left there is, uh, a JSON object that is used to control the, uh, the device remotely. Uh, it's going to have kind of like the type of object that it's supposed to be. And then in the, this ID mode is going to give the, um, the Mac address of the butt plug that is supposed to be, uh, controlled as well as the command. So V means vibrate. Um, and, um, and that's what's going to be sent over as JSON to, uh, to the remote app. Now, how does the remote app kind of use this? Uh, the thing that we can kind of think about here is that basically if we're able to somehow hijack this and to allowing us to send an arbitrary string over to the dongle, we can actually exploit the dongle JSON parser bug in order to get code extrusion there and then use that to kind of get code extrusion back on the app. Uh, so it's kind of convoluted, but it turns out it totally works. Uh, the reason for that is that it doesn't actually properly check that the incoming data for like the vibrate command is actually an integer. Uh, it does try to do that check. Uh, if you take a look on the right there, uh, at the, uh, at the top, uh, in the ID mode, uh, it does check that n, which is the incoming, uh, vibration, uh, you know, strength data, is greater or equal than zero. Uh, and what that does is that it actually effectively checks that it's an integer that is positive. The reason for that is that if you can take a look on the left there, uh, on JavaScript, if you do 12 is greater or equal than zero is going to tell you yes. Uh, even if it's a string, it's going to tell you yes. Now if it's a string that also includes some text that is not, uh, a number, it's going to tell you no, it's not, that's not going to work, so that's going to block us. That's what makes it such that you can't just arbitrarily, uh, inject, uh, a command into there. However, uh, if you take a look at the bottom there, it has the exact same check, but instead of checking that n is greater or equal to zero, it's checking that n is not, uh, less than zero. And the problem there is, well, if you check that it's not less than zero, then yes, the string is also going to tell you that it is, uh, that it is not less than zero. But if you then, you know, kind of reverse that, it's actually going to tell you it's true, even though it's not an actual string. Uh, well, even though it's not an actual integer. Uh, so it's kind of unfortunate, I'm not sure why they decided to like flip that test, uh, that test there, like the filter. Uh, but essentially it means that we can, uh, inject an arbitrary string into this command that's going to be sent over to the dongle, and that allows us to send the exact same, uh, exploit code that we sent over earlier that allowed us to, uh, to compromise the dongle for the, uh, JSON parser. So basically the only difference here is that we can just do it over the internet, uh, basically exploit this firmware bug over the internet just because they, you know, flipped, uh, uh, a check, which is unfortunate. Uh, so this point, you know, we have actually our viral, uh, but plug worm, um, is going to allow us to kind of, uh, compromise the dongle, which allows us to compromise the app, and then we can go from app to app. Uh, the only problem here is that we can only do this assuming that the remote partner has accepted our request to control our toy. Um, but, uh, it turns out you can actually get code extortion on the remote app in a much simpler way, which is that they have, uh, a chat, uh, feature where you just can send text. Turns out you can't just send text, you can also send HTML. Uh, so kind of sending the exact same thing as before, sending this message, you can pop alert. Um, again, unfortunate, this is kind of a very basic, uh, web dev stuff, uh, because I could find it and I'm definitely not a web dev, so. At this point we can get code extortion just by sending a message. Uh, so we basically achieved our goal. Uh, this is a payload they ended up using. Uh, it's going to both, uh, you know, spawn a local process to get code extortion on the actual device, maybe do some ransomware, and then it's going to also send that message to all your friends and create, uh, basically a, um, a completely viral, um, you know, exploit here. So we've compromised every node in the network, which is what we wanted to do. So, uh, you know, yay, go us. And that means it's time for a live demo. A little tired trying to remember how all of this all works. Uh, you can all see this. So, uh, please bear with me. Uh, so the first thing I'm going to show you is, uh, this I'm going to be actually using BTLE jack to kind of like try to hijack a connection between a butt plug and this, uh, VM right here. Uh, this VM, which hopefully works. Okay. So this VM is just a regular Windows VM, it's connected to the dongle, uh, because VMware lets you do that. And I'm going to turn on this butt plug. I hope you can hear it. Um, so this works. It's on. Then you can kind of add a toy. Hopefully that's going to work as well. Oh wait shit, I forgot to do something. Okay. Let's start over. Okay. So it did connect. That's cool. But, uh, it didn't, I'm a dumbass. Come on. So I actually want to disconnect this because I forgot to start the BTLE jack process on the same, uh, side. Uh, the only reason that we're doing BTLE jack in this mode is that it's going to be, uh, more successful, uh, for a live demo. But in theory, well, I mean, not just in theory, actually in practice, we can also hijack an existing connection without having to sniff it while it's happening. So this is just to make things easier. Okay, so now we're going to do this again. Connect the toy. Hopefully the sniffers are going to detect that connection. Alright. It detected a connection on the left there. That's pretty good. Okay. And then we have this app that's connected to our sex toy. Alright. So we can actually control it. I don't know if you can hear it. It's there. You gotta stop it. Okay. Alright. It stopped. From here, we should be able to actually hijack this connection. Uh, the way we do that is, I'm trying to remember this. Oh my God. I used to have a mouse for this. It was much easier. Okay, then we copy this parameter. I'm just really sorry about this. Um, gotta try and make it faster. Alright. And team which means hijack. So we're going to try and hijack this connection here. And if it works, it should, uh, kill the connection. This happens. It should just happen. In case it is trying to hijack, it hijack the connection. So that's great. Thank you BTLE Jack for a great tool. Uh, so from here what you can see is that in here, in the app, it actually disconnected because we now have control of the butt plug from Ubuntu. Uh, and so in theory, we should be able to make it, uh, for example, vibrate remotely. Uh, no, SDR vibrate 20s. Oh, not site rate. God damn it. Uh, 20. Uh, it's actually happening there. Uh, so, so that works. That's great. Now we're going to put this into DFU mode. Hopefully that also works. It should stop it if it works. There we go. It stopped. Okay, so now it's actually in firmware update mode. So at this point I take my phone, I'm going to try and connect it. Hopefully it works again. Uh, yeah. Alright, cool. So from here, please don't look at my apps. Please don't send me any messages right now. Uh, so we're going to grab the firmware version, uh, for the exploit, version 27. It's a lot of work. Uh, and we should be able to say DFU target. So okay, so now we're going to be flashing this new firmware from our phone, uh, sub-dating. And just keep this here for now. And from here, uh, what we're going to do, assuming this works. Alright, it's been updated. So now what we can do is pull this up and, uh, try to connect back to it. Oh, I think it's doing it on its own. Let's see. And so, so this worked. Uh, at this point we have gotten connection on the dongle and then back on the computer through this. We downloaded an exe from the internet and we ran it. Uh, and unfortunately encrypted our butt plug which, uh, you know, it's unfortunate. Uh, it's probably from North Korea. And then what we can see is that I had this other, uh, VM which was also running the app. This one is not connected to a dongle or anything, as you can tell. Uh, but it is connected to the internet and it's like my friend. Uh, and so, had a message and it just runs the exact same thing. Uh, so we've achieved like butt plug virality, uh, with this infected butt plug. Don't connect to it right now unless you want to like, you know, uh, get your butt plug encrypted. Um, and, and yeah, I mean that's, that's basically it. Uh, the conclusion, well, okay. I think there's a couple lessons that we can learn from this, um, which is, you know, as I mentioned, you know, as much as this is kind of like a funny line of research, uh, in my opinion it is actually kind of important to, uh, look at the security posture of these devices. Not only because it is actually used by people for their livelihoods, but also because in my opinion it is kind of, uh, uh, very representative of the current state of, you know, IOT and connected devices in general. It's kind of like all these different technologies which are both new and not new, uh, kind of like working together and people don't necessarily understand all the implications of like having one vulnerability in one there, uh, in one component there is that you can kind of start chaining these things and, uh, turn, you know, an XSS into, uh, a butt plug firmware, uh, hack or like, uh, a USB dongle hack that should only be possible locally ends up being exposed to the internet and stuff like that. So, you know, hopefully this kind of, uh, research applies to other things. Um, and I wanted to say something else, but I completely forgot what it was. So, uh, I guess thanks for listening. And if you want to find all the code, uh, that was, uh, in there, uh, go follow me on Twitter. I'm going to post this on GitHub later today. If you want to start hacking your own butt plugs. And I do want to thank, uh, all my friends who helped me, uh, make this, all my friends who also introduced me to, uh, the world of connected butt plugs, uh, who are extremely gay. Uh, I'm not going to name names, but you know who you are, Aaron. Uh, all right. And thank you very much.