Adventures In Smart Buttplug Penetration (testing)
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
smea
Analysts believe there are currently on the order of 10 billions Internet of Things (IoT) devices out in the wild. Sometimes, these devices find their way up people's butts: as it turns out, cheap and low-power radio-connected chips aren't just great for home automation - they're also changing the way we interact with sex toys. In this talk, we'll dive into the world of teledildonics and see how connected buttplugs' security holds up against a vaguely motivated attacker, finding and exploiting vulnerabilities at every level of the stack, ultimately allowing us to compromise these toys and the devices they connect to.
 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've 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 it 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 years, um, or a couple years, I mean like, past few decades even actually, there's been the emergence of this, uh, new field called, uh, teledonics. Um, look at the etymology for this, uh, you know, it's from the Greek telé 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 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, no, 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, 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 at this, like people actually do rely on these, on these, 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 but 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 to it. Um, they, the company that makes this but plug actually has a patent on the concept of tipping money over the internet to control but 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 but 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 but plugs. One of them is just gonna be okay, well, you're, you're using this locally and someone is within vicinity notices that you have a but plug in and tries to hijack that connection. Uh, there's actually already been a bunch of research into this, so there's not gonna be a primary for, 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 gonna be, um, it's gonna be, uh, 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 devices or compromise your but 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, in kind of what we're gonna be focusing on. Uh, and the third compromising scenario, uh, would be the opposite. Uh, thinking about having someone who has a hostile but 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 but 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 the whole world of Teledonics, what does it look like in practice? Uh, this is the Levin's Hush, uh, which I will be doing live demo on later on just FYI. Uh, it's billed as the world's first Teledonic but plug. Uh, as mentioned, it's a but plug. Uh, I'm gonna just be saying but plug a lot in this talk just a bit of a way. 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 the law of events. So the same company that needs to be able to use these but plugs and uh, and yeah, it's like five dollars. It's kind of interesting we were gonna 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 but plug over to someone else. So in terms of the, you know, kind of like the 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 but plug and the uh, dongle and then the dongle obviously connected with USB uh, and so on. Right? Uh, so the question here is what can you, what does it look like for each compromised scenario? Well for the local case is just compromised 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, 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 uh, compromise one app from the other. And the third scenario uh, is going to be trying to hack into the but 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 but plug obviously it's, well, I mean not obviously, there is actually an open source uh, but plug project apparently. Um, no I'm not, I'm not 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 but plug, I don't have the code for the dongle so what do we do? Well 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 uh, platform app. It works on both Windows and Mac OS so of course it's an electron app so of course everything is written on, on JavaScript. I don't love JavaScript 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, reverse engineer. Uh, it is obfuscated but you can just throw it 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 uh, and the computer app are all on 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 uh, you know 32 bit microcontroller, it's kind of weird to have to embed a JSON parser in there. And for us it's a good thing though because JSON parsers uh, you know, it's a parser that will probably be bugging 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 uh, 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 uh, 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 uh, see what it looks like. Uh, from there you 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, you can kind of see how it looks, start reversing, nearing. Notice, notice two things. Um, first thing is it has two command handlers over USB uh, USB-0. One of them is like these simple commands uh, such as reset or like asking for device type stuff like that. The other one is it basically if it doesn't find a um, a simple command is going to throw into a JSON parser which is what 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 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 uh, commands and get it into uh, 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 the, the, 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 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, null terminator and make it such that the uh, string length that was calculated first is uh, is wrong. So 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'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 codexed in 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, uh, 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 stacker keys so it's basically hacking like 1999 assuming there's no depth, which is pretty cool. Uh, turns out the sock is just a Nordic Semi-Canada sock, uh, very classic uh, sock using uh, a bunch of uh, BLEA OT 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 uh, 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 have the stack basically is being dumped and the stack has been completely overwritten with just A 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 kind of you know, authenticate the update in any possible way. Turns out it kind of 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 kind of figured that well, who cares about getting you know, code execution on the USB but plug 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, I, 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. 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 the 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 bug plug because you know, that's kind of what we do. Um, looking at the hardware on the bug plug 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 semi conductor 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 the dongle so it's pretty easy. And there's a bunch of other things that were not on the uh, the USB dongle board but there are a few things that were which is the SWD uh, test points so that we can actually debug a bug plug. And this is what it looks like in practice. Uh, I'm kind of terrible at soldering but I do have a bunch of bug plugs like this that are opened uh, in my bag. Um, uh, so you know, I, 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 bug plug is that you can actually use this to dump the firmware. Uh, and from there, you know, kind of figured that if the dongle update mode was so insecure, um, maybe the, you know, maybe the bug plug 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 sent 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 kind of dump the, the bug plug 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 uh, a little wire shark uh, uh, trace here that kind of just see uh, has uh, the uh, the bug plug sending back uh, a little message saying hello from plug. Uh, which means that yes we, obviously we just got correct solution on the bug plug by not even doing anything. There's no vulnerability here. It's just, it's just kind of by design you can uh, reflash it which might be love and says 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 bug plug at this point can get correct solution on it. Um, which seems kind of dangerous. At this point, we do still require uh, being local. Like being in the physical vicinity of the bug plug 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 bug plug, what can we do with this? Well, there's a few ideas that I had. First one is if you can get correct solution on the bug plug, you can actually create bug plug 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 bug plug ransomware. Uh, kind of bug plug vaccine if you will. Uh, so this is a one scenario that could work. I noticed an area that is kind of interesting but I did not really look into that much. Is the idea of like weaponizing a bug plug or any other sex story like physically. Um, and you know, in the case of a bug plug 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 bug plug is 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, 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 the 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 is says, that's 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 going to 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 going to be yes, but for now I'm going to pretend that we don't know that. So, uh, interestingly, uh, well at this point we have code execution on the 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 way that 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 findDongle which basically just handles uh, one of the initialization messages that comes from the dongle. Uh, the second one is onData. 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 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 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 bug plug dongle. Uh, so from there basically if you have control over 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 is just yeah, you just compromise the computer because there's no sandbox or anything. So the question is can we actually do that with our limitation of having only 32 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 up there. Uh, you have an uh, an image uh, tag with a source that doesn't exist and then you have the on error 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 coding of the app. So that's problematic. Uh, it's kind of annoying to get a huge payload just because of um, the fact that we can only do 32 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 a 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 character length limitation on the messages that are coming from uh, from the bug plug to the 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 just, just grabs incoming data. If it sees it's more than 20 characters it just kind of cuts it there and copy, 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, not 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. Uh, unfortunately I did 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, problem here is yeah we can't actually use this to get codex version directly on the app from the bug 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 uh, of uh, you know, um, memory corruption vulnerabilities in the actual bug plug specific code. However, uh, the one thing that's pretty cool is that there's way more code on this microcontroller than just the bug 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, is basically a driver for that sock that was written by uh, Nordic semi-conductors 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 low energy stack. That's just what we did. Uh, in order to hack a bug plug we were finding Bluetooth vulnerabilities. Um, and uh, and yeah, so, so because we, we can kind of debug it, um, debug that bug plug or the, or 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 general attribute protocol, um, for, for central mode messages I guess. Um, and so uh, what, what I'm showing specifically is actually uh, the 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 uh, 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 you a certain type and then it's going to return all the handles for all the attribute services that are uh, 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, 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 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, zero xd handle and then a pointer that points to that data like the data in blue that is associated with it. And then 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 zero there basically you end up with an unbounded uh, infinite 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 stack or keys or you know ASLR or DEP or anything you basically immediately have code execution. In this case the problem is uh, because you have uh, value zero 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 one 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 going to be able to corrupt everything that's near it. So taking a look at before uh, what happens when you do actually use this uh, overflow on the stack and yellow is going to be the attribute buffer that I was mentioning. Then 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 uh, run the vulnerability is 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 low, the less significant bytes of uh, of um, of d words every uh, 8 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 pretty cool. Um, thing is uh, you know the Cortex, Cortex M0 CPU actually does not support arm mode so we do have an alignment uh, uh, requirement on that return address, it has to be uh, you know, aligned to 2 plus 1 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 were 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 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 shellcode 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 shellcode 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 uh, 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 the 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 uh, compromised 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 into the uh, original dongle code and uh, start sending uh, you know the serial data that we're talking about. So this is what 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 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 devices assuming that it's configured 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 uh, 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 uh, 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.mil on Windows. It turns out it actually just gives us kind of everything. We can access all the, all the files on the file, on the computer. We can execute arbitrary code. Uh, just spawn uh, an EXE that we want. Um, so we basically kind of compromise the computer just by uh, by doing this. Uh, which is you know, kind of great. Um, 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, 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 we 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, 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 uh, the MAC address of the bug plug that is supposed to be controlled as well as the command so V means vibrate. Um, and uh, 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 bottom, at the top, uh, in the ID mode, uh, it does check that N which is the incoming vibration, uh, you know, strength data is greater or equal to 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, it's 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 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 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 at this point, you know, we have actually our viral, uh, bug plug worm, um, it's 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 codex execution 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, uh, 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 codex execution just by sending a message. Uh, so we basically achieved our goal. Uh, this is a payload that we ended up using. Uh, it's going to both, uh, you know, spawn a local process to get codex execution 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 that it's time for a live demo. All right. 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 VM where it lets you do that, and I'm going to turn on this butt plug. Uh, and this is a VM that I'm going to use to, uh, use the VM, uh, to, uh, use the VM, uh, to, uh, use the VM, uh, to, uh, use the VM, uh, VM where it 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, 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 detects the 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've got to stop it. Okay. Alright, it stopped. From here, we should be able to actually hijack this connection. Uh, the way we do that is, try 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 to 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 in this app and it should just happen. Okay, so it's trying to hijack, and it hijacked 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 bug 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. So 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, it's updating. Okay, 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 VM which was also running the app. This one is not connected to a dongle or anything, as you can tell. 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 basically it. Uh, the conclusion, well, okay. I think there's a couple lessons 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 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, 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 the 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, alright. And thank you very much. Thank you.
 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've 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 it 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 years, um, or a  couple years, I mean like, past few decades even actually, there's been the emergence of this, uh,  new field called, uh, teledonics. Um, look at the etymology for this, uh, you know, it's from the  Greek telé 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 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, no, 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, 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 at this, like people  actually do rely on these, on these, 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 but 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 to it. Um, they, the company that makes this but plug actually has a  patent on the concept of tipping money over the internet to control but 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 but 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 but plugs. One of them is just gonna be okay,  well, you're, you're using this locally and someone is within vicinity notices that you have a  but plug in and tries to hijack that connection. Uh, there's actually already been a bunch of  research into this, so there's not gonna be a primary for, 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  gonna be, um, it's gonna be, uh, 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 devices or compromise your but 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, in kind of what we're gonna be focusing on. Uh,  and the third compromising scenario, uh, would be the opposite. Uh, thinking about having  someone who has a hostile but 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 but 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 the whole world of  Teledonics, what does it look like in practice? Uh, this is the Levin's Hush, uh, which I will be  doing live demo on later on just FYI. Uh, it's billed as the world's first Teledonic but plug. Uh,  as mentioned, it's a but plug. Uh, I'm gonna just be saying but plug a lot in this talk just  a bit of a way. 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 the law of events. So the same company that  needs to be able to use these but plugs and uh, and yeah, it's like five dollars. It's kind of  interesting we were gonna 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 but plug over to someone else. So in terms of the, you know, kind of like the  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 but plug and the uh, dongle and then the dongle  obviously connected with USB uh, and so on. Right? Uh, so the question here is what can you,  what does it look like for each compromised scenario? Well for the local case is just  compromised 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, 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 uh, compromise one app from the other. And the third scenario uh, is going to be trying to  hack into the but 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 but plug obviously it's, well, I mean not obviously, there is actually an  open source uh, but plug project apparently. Um, no I'm not, I'm not 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 but plug, I  don't have the code for the dongle so what do we do? Well 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 uh, platform app. It works on both Windows and  Mac OS so of course it's an electron app so of course everything is written on, on  JavaScript. I don't love JavaScript 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, reverse engineer. Uh, it is obfuscated but you  can just throw it 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 uh, and the computer app are all  on 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 uh, you know 32 bit microcontroller, it's kind of weird to have to embed a JSON  parser in there. And for us it's a good thing though because JSON parsers uh, you know,  it's a parser that will probably be bugging 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 uh, 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 uh, 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 uh, see what it looks like. Uh, from there you 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, you can kind of see how it looks, start  reversing, nearing. Notice, notice two things. Um, first thing is it has two command  handlers over USB uh, USB-0. One of them is like these simple commands uh, such as reset or  like asking for device type stuff like that. The other one is it basically if it doesn't  find a um, a simple command is going to throw into a JSON parser which is what 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 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 uh,  commands and get it into uh, 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 the, the, 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 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, null terminator and make it such that the uh, string length that was calculated  first is uh, is wrong. So 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'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 codexed in 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, uh, 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 stacker keys so it's basically hacking like 1999 assuming there's no depth,  which is pretty cool. Uh, turns out the sock is just a Nordic Semi-Canada sock, uh, very  classic uh, sock using uh, a bunch of uh, BLEA OT 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 uh, 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 have the stack basically is being  dumped and the stack has been completely overwritten with just A 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 kind of you know, authenticate the update in any possible way.  Turns out it kind of 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 kind of figured that well, who cares about getting you know, code execution on the USB  but plug 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, I, 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. 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 the 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 bug plug because you know, that's kind of what we do. Um, looking at the hardware on the  bug plug 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 semi  conductor 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 the dongle so it's pretty easy. And  there's a bunch of other things that were not on the uh, the USB dongle board but there are a  few things that were which is the SWD uh, test points so that we can actually debug a bug  plug. And this is what it looks like in practice. Uh, I'm kind of terrible at soldering but I do  have a bunch of bug plugs like this that are opened uh, in my bag. Um, uh, so you know, I, 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 bug plug is that you can actually use this to dump the firmware. Uh,  and from there, you know, kind of figured that if the dongle update mode was so insecure, um,  maybe the, you know, maybe the bug plug 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  sent 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 kind of dump the, the bug plug  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 uh, a little wire shark uh, uh, trace  here that kind of just see uh, has uh, the uh, the bug plug sending back uh, a little message  saying hello from plug. Uh, which means that yes we, obviously we just got correct solution on  the bug plug by not even doing anything. There's no vulnerability here. It's just, it's just  kind of by design you can uh, reflash it which might be love and says 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 bug plug at this point can get correct solution on it. Um, which seems kind of  dangerous. At this point, we do still require uh, being local. Like being in the physical  vicinity of the bug plug 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 bug plug, what can we do with this? Well, there's a few ideas that I had.  First one is if you can get correct solution on the bug plug, you can actually create bug plug  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 bug plug ransomware. Uh,  kind of bug plug vaccine if you will. Uh, so this is a one scenario that could work. I noticed  an area that is kind of interesting but I did not really look into that much. Is the idea of like  weaponizing a bug plug or any other sex story like physically. Um, and you know, in the case of  a bug plug 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 bug plug is 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, 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 the 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 is  says, that's 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 going to 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 going to be yes, but for now I'm going to pretend that we  don't know that. So, uh, interestingly, uh, well at this point we have code execution on the  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 way that 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 findDongle which basically just handles uh, one of the initialization messages that  comes from the dongle. Uh, the second one is onData. 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 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 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  bug plug dongle. Uh, so from there basically if you have control over 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 is just  yeah, you just compromise the computer because there's no sandbox or anything. So the  question is can we actually do that with our limitation of having only 32 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 up there. Uh, you have an uh, an image uh,  tag with a source that doesn't exist and then you have the on error 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 coding of the app. So that's problematic. Uh, it's kind of annoying to get a huge  payload just because of um, the fact that we can only do 32 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 a 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 character length limitation on  the messages that are coming from uh, from the bug plug to the 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 just, just grabs incoming data. If it sees it's  more than 20 characters it just kind of cuts it there and copy, 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, not 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. Uh, unfortunately I did 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, problem here is yeah we can't actually use this to get codex version directly on the  app from the bug 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 uh, of uh, you know, um, memory  corruption vulnerabilities in the actual bug plug specific code. However, uh, the one thing  that's pretty cool is that there's way more code on this microcontroller than just the bug  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, is basically a driver for that sock that was written by uh, Nordic semi-conductors  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 low  energy stack. That's just what we did. Uh, in order to hack a bug plug we were finding  Bluetooth vulnerabilities. Um, and uh, and yeah, so, so because we, we can kind of debug it,  um, debug that bug plug or the, or 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  general attribute protocol, um, for, for central mode messages I guess. Um, and so uh, what,  what I'm showing specifically is actually uh, the 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 uh, 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 you a certain type and then it's going to  return all the handles for all the attribute services that are uh, 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, 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 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, zero xd handle  and then a pointer that points to that data like the data in blue that is associated  with it. And then 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 zero there basically you end up with an unbounded  uh, infinite 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 stack or keys or you know ASLR or DEP or anything you basically  immediately have code execution. In this case the problem is uh, because you have uh,  value zero 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 one 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 going to be able to corrupt everything that's  near it. So taking a look at before uh, what happens when you do actually use this uh,  overflow on the stack and yellow is going to be the attribute buffer that I was mentioning. Then  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 uh, run the vulnerability is 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 low, the less significant bytes of uh, of um, of  d words every uh, 8 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  pretty cool. Um, thing is uh, you know the Cortex, Cortex M0 CPU actually does not support  arm mode so we do have an alignment uh, uh, requirement on that return address, it has to  be uh, you know, aligned to 2 plus 1 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 were 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 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 shellcode 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 shellcode 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 uh, 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 the 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 uh, compromised 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 into the uh, original dongle code and uh, start sending uh, you know the serial  data that we're talking about. So this is what 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 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 devices assuming that it's configured 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 uh, 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 uh, 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.mil on Windows. It turns out it actually just gives us kind of  everything. We can access all the, all the files on the file, on the computer. We can  execute arbitrary code. Uh, just spawn uh, an EXE that we want. Um, so we basically kind of  compromise the computer just by uh, by doing this. Uh, which is you know, kind of great. Um,  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, 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 we 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, 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 uh, the MAC address of the bug plug that is supposed to be controlled as well as the command  so V means vibrate. Um, and uh, 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 bottom, at the top, uh, in the ID mode, uh, it does check that N which is the incoming  vibration, uh, you know, strength data is greater or equal to 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, it's 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 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 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 at this point,  you know, we have actually our viral, uh, bug plug worm, um, it's 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 codex  execution 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, uh, 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 codex execution just by sending  a message. Uh, so we basically achieved our goal. Uh, this is a payload that we ended up using. Uh,  it's going to both, uh, you know, spawn a local process to get codex execution 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 that it's time for a live demo.  All right. 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 VM where it lets you do  that, and I'm going to turn on this butt plug. Uh, and this is a VM that I'm going to  use to, uh, use the VM, uh, to, uh, use the VM, uh, to, uh, use the VM, uh, to, uh, use the VM, uh,  VM where it 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, 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 detects the 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've got to stop it.  Okay. Alright, it stopped. From here, we should be able to actually hijack this connection. Uh,  the way we do that is, try 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 to 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 in this app and it should just happen.  Okay, so it's trying to hijack, and it hijacked 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 bug 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. So 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, it's updating. Okay, 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 VM which was  also running the app. This one is not connected to a dongle or anything, as you can tell. 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 basically it. Uh, the conclusion, well, okay. I  think there's a couple lessons 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 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,  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 the 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, alright. And thank you  very much.  Thank you.
smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_0_83.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_84_13907.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_13908_15239.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_15240_15707.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_15708_16595.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_16596_17363.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_17364_17411.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_17412_18275.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_18276_19535.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_19536_19895.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_19896_20819.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_20820_21395.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_21396_23171.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_23172_24347.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_24348_25355.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_25356_25883.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_25884_28535.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_28536_29279.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_29280_32795.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_32796_33671.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_33672_34403.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_34404_39431.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_39432_42755.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_42756_45803.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_45804_51947.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_51948_52823.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_52824_52871.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_52872_53531.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_53532_56159.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_56160_56615.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_56616_57035.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_57036_57899.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_57900_58319.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_58320_58475.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_58476_58547.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_58548_58595.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_58596_58799.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_58800_59003.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_59004_60095.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_60096_60203.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_60204_60347.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_60348_61127.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_61128_62003.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_62004_62075.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_62076_62423.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_62424_64583.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_64584_64787.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_64788_65519.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_65520_66239.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_66240_67343.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_67344_68339.png smea_-_Adventures_In_Smart_Buttplug_Penetration_te_RnxcPeemHSc_68340_68347.png