>>Uh next up we have Smea
talking about real penetration
testing. Please give him a warm welcome. [applause]>>Alright uh
hi everyone uh as mentioned I am
Smea and today I will be talking about how to hack a buttplug. Um
this is 1 of those just FYI, I
don’t know if you’ve ever seen 1 in person, I had not. Um but
I’ve been introduced to a lot of
things over the past 2 years so, you know, here we are. Uh you
might be wondering what’s like,
what does it even mean to hack a buttplug? Because you know if-
if you take a look at this it’s
basically just like a piece of silicone, obviously you are
supposed to put it somewhere.
Umm [audience groans] there’s not much to it right? You don’t
really need uh any electronics
in here. But over the past couple years- uh or couple of
years I mean like past few
decades even actually there’s been uh the emergence of this uh
new field called uh
teledildonics. Um look at the etymology for this, uh you know
it’s from the Greek tele which
means from afar uh and the English dildo which apparently
just means dildo. There’s no
origin I tried to look it up uh no one knows where this word
came from. Uh but yeah it’s-
it’s pretty self explanatory, right? The idea is that you want
to make sex toys that are
controlable remotely uh, in- in some way. Uh it actually uh you
know enables a number of
different scenarios. Um basically [laughter] I ju- I
just want to explain to you
because not everyone is familiar with this field, ok? Just want
to explain how this works. Uh so
you take this butt plug right, uh you insert it [laughter] um
eh and from there you- you-
you’re actually able to like control it from eh 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 it’s just you end up
giving control to you know
someone else. [laughter] Now this is- this is an actual
thing. Um and so they actually
advertise this for like oh you can like go up 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
gonna be the same thing, you give control over to someone
else but this time it’s gonna be
over the internet. Um and you can- you know you can kind of
think of that as it’s probably
not gonna be a stranger but it might be. Uh it’s gonna 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
[laughter] I’m not trying to make a joke out of this. Like
people actually do rely on these
uh 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 buttplugs yes that’s funny but people do
actually make a livelihood off
of this, right? Uh it’s like some scenarios are gonna be you
know cam girls, cam boys, uh
whatever you wanna call them, people who uh basically provide
dynamic you know sex
entertainments uh over the internet 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 toy.
Um they the company that makes this butt plug actually has a
patent on the concept of tipping
money over the internet to control a buttblug. Um which you
know that’s a whole nother
debate but it is kind of interesting. The- 1 of the
scenarios also is like you can-
you can either yeah uh have it vibrate in exchange for you know
a 5 dollar tip or something, but
it can also be you create a link to control your buttplug 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 posture is here. Uh
and so the security posture like
let’s think about scenarios that are interesting for- for us in-
in terms of hacking these butt
plugs. 1 of them is just gonna be ok well you’re you’re using
this locally, and someone is
within the vicinity, notices that you have a butt plug in and
tries to hijack that connection.
Uh there’s actually already been a bunch of research into this so
that’s not going to be our
primary focus- 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. Uh second
scenario that’s kind of interesting [scattered applause]
is gonna be um. Is 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- your devices, or compromise your
butt plug, or do whatever, do
something bad. Uh so that’s a compromise scenario that’s
totally legit and uh and- and
more interesting in my opin- in my opinion uh and kind of what
we’re going to be focusing on.
Uh and the third compromising scenario uh would be the
opposite, uh thinking about
having someone who has a hostile butt plug basically uh
[laughter] who might be able to
hack back into your computer, into your phone or whatever, and
then possibly hack into whoever
is connected on the other end; uh which is the other scenario
that I don’t think people
realize this is a real risk of you know the hostile butt plugs
in this world, so [laughter]
This is something that we will be exploring. Taking a look in
practice. Uh now that we’ve uh
you know introduced the whole world of teledildonics, what
does it look like in practice?
Uh this is the Lovense Hush uh which I will be doing a live
demo on later on, just FYI. Uh
it’s billed as the world’s first teledildonic butt plug. Uh as
mentioned it’s a butt plug. Uh
I’m gonna just be saying butt plug a lot in this talk just FYI
[laughter] 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 Mac OS and Windows. Uh and on Windows you
actually do need to use a
special USB dongle which I would show you but it’s plugged into
my computer right now. Uh so
that dongle is made by Lovense, so the same company that makes
these b- these butt plugs. And
uh and yeah it’s like 5 dollars it’s kind of interesting we’re
gonna look into that. Uh and
then you know the app actually introduces uh social features so
you can uh chat, video chat, uh
send pictures, and then obviously give control to your
butt plug over to someone else.
So in terms of uh 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 butt plug
and the uh dongle and then the dongle obviously is connected
over USB uh and so on, right? Uh
so the question here is: what can you- what does it look like
for each compromise scenario?
What- well for the local case it’s just compromise scenario 1,
you just want to compromise the
BLE connection. Uh again there’s already been research in this,
uh basically there’s no security
there; anyone can uh kinda 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 s-
uh scenario for compromise was
over the internet so we kind of hijacking that connection
somewhere or thinking about uh
seeing how you can uh compromise 1 app from the other. And the
first scenario uh is going to be
trying to hack into the butt plug, trying to hack into the
dongle, trying to hack into the
app, each from 1 to the other uh and so that actually involves a
lot more research. Uh the
question is you know this is a butt plug obviously it’s- well-
I mean not obviously, there is
actually an open source uh butt plug project apparently. Um
[laughter] No I’m not- I’m
making a joke. It’s apparently good work. Um and uh so the
question is well where do we
start right? I- I- I started working on this, I was like
“Well I don’t have- I dont have
the code for the butt plug I don’t have the code for the- the
dongle so what do I do?” Well
the PC app you can just download it and put it into IDA and see
what happens. Um turns out you
actually don’t even need to put it into IDA, because of course
it’s a multi- uh platform app,
it works on both Windows and MacOS so of course it’s an
electron app so of course
everything is written not in 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 en- reverse engineer.
Uh it is obfuscated but you can just throw it in to 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 uh allows you to start then sniffing the connection
between the dongle and uh the
app. And 1 thing that you will notice uh the uh- the sniffing
uh data is on the right here; is
that all these messages being sent between the dongle and the-
and the computer app are all in
JSON. Uh which is kind of interesting because, well JSON
is obviously you know native for
javascript apps and stuff so that’s convenient. However for a
USB dongle that is just
basically a you know- a 32 bit microcontroller, it’s kind of
weird to have- to embed a JSON
parser in there. And for us it’s- it’s a good thing though
because JSON parsers uh you know
it’s a parser, there will probably be a bug in there.
Turns out there is a bug in
there. Um but it’s kind of annoying to uh to take a look at
that without having the code of
the- 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 uh firmware
updates for the uh USB dongle.
From there you can find the URL from which to dow- 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 we can kinda 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 kinda
see how it looks, start reverse
engineering you notice- whoops. Notice 2 things. Um first thing
is it has 2 command handlers
over USB, uh USB serial. 1 of them is like these simple
commands uh such as reset or
like asking for the vice types stuff like that. The other 1 is
it basically if it doesn’t find
a um a simple command it’s going to throw it into the JSON parser
which is what we expected uh and
that’s where we can start looking for bugs. 1 thing that
is interesting is uh in the
process symbol command’s uh function is it does have a
command for DFU uh so that’s
device firmware update. So as expected we do actually have the
ability to uh to send these uh
commands and get it into um uh- firmware update mode. But
looking into the JSON parser
which is uh what we’re interested in here. Uh of course
we end 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 new buffer, copy the
initial string into the uh- the-
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 it calculates the
len- the length of the new
buffer that it’s going to allocate then it allocates it
and then it does that copy and
so of course there’s a mismatch between uh the length that it
calculates and the length that
it’s going to um actually use at- at- at the end there. Uh the
way that it works is that it
supports uh you know the uh U escape character sequence uh
which takes 5 parameters instead
of just you know 0 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 it’s a little animation here.
Um. What’s going on here is that
it starts calculating the length, it runs into this escape
character so it skips a
character and then it finds the null- k- null terminator and
that’s the string uh- string
length it’s calculating. Then this loop that actually copies
into that buffer. What happens
is it runs into the escape character, uh sequence. So it
says ok there’s a backslash
there’s a U that means that I need to skip 6 characters. And
so it’s actually skipping over
the uh null terminator, which is uh a problem. And then just
kind- it kind of keeps going,
it’s going to be copying all these characters into that
buffer which is only 6 bytes in
length. So obviously there’s a problem, we can uh overflow out
of the- out of this buffer and
kind of just get code execution 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 DEP or anything like that. Which uh kind of complicates um
exploitation. So we do know
there’s no SLR there’s no stack cookies, so it’s basically
hacking like it’s 1999 assuming
there’s no DEP which is pretty cool. Uh turns out the SoC is
just a Nordic semiconductor SoC,
uh very classic uh SoC using uh a bunch of BLE IOT 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
the sudden we can just debug this um- this dongle which is
pretty great. Being able to
debug the dongle, we can kinda dump the contents of the heap.
See what’s there. It turns out
the heap is only used for the uh JSON allocators, uh the JSON
parser so that’s not super great
but it does also include uh metadata. So what you’re gonna
see here is that uh for each
allocation you have a length field as well as a um, as a uh
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 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
0 like a big enough value uh we’ll 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 arbitrary
location. We can do this while
the debugger uh connected and as you can see on the right here,
um we- we have the stack
basically is being dumped and the stack has been completely
overwritten with just 8
characters uh that gives us code execution on the USB dongle and
uh that’s pretty cool. Um from
there uh we unfortunately remembered 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, they just kind of figured that
“Well, who cares about getting
you know code execution on a USB butt plug dongle. Uh turns out I
do. Uh so that’s
unfortunate.[laughter] Uh but it is- it is uh interesting uh at
this point basically we have 2
different ways of getting code execution on this dongle uh and
the do- the JSON Parser way you
know I- I- that I mentioned I spent a lot of time on it, might
not seem very useful because we
have a device firmware update mode but it turns out is
actually going to come up again
later with uh- with another vulnerability that we’re gonna
chain together so, you know I- I
didn’t just say all that for nothing. The point is, we can
get code execution, uh we can
flash on firmware, which is pretty great. So at this point
we have a compromised USB dongle
from a 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 want to like
figure out a way to somehow get code execution on the butt plug
because you know- that’s kind of
what we do. Um looking at the hardware on the butt 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 s- very
similar SoC, uh so it’s another Nordic semiconductor SoC uh it’s
a little bit beefier, it’s an M4
instead of an MM0, it has more flash, has more ram, it’s 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 DEP, there won’t be any like
more advanced mitigations on
the- on the dongle so it’s pretty easy. From there 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 point so with that we can actually debug a butt
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 buttplugs like
this that are opened uh in my bag. Um [laughter] uh so you
know I- I don’t know why I’m
telling you this but this is pretty cool. Uh [laughter] from
there uh the nice thing about
being able to debug a butt 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 uh
maybe the- you know maybe the buttplug also had an update mode
which is also super insecure. Uh
it turns out that yes it does, if you send it the same- the
exact same DFU command that you
sent the dongle, it will also go into device firmware update
mode. And from there you-
there’s actually an app that uh Nordic ships which is the nRF
Toolkit app, uh or Toolbox app,
it will just let you flash new firmware to it. Uh at this point
we don’t actually know the DFU
mode is uh- as insecure as 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
buttplug firmware from uh from
SWD, modify it, compute the new CRC16, send it over. And this
way you can see uh on the right
here is the you have WireShark uh the little WireShark uh trace
there that kind of just see, uh
has uh, the uh- the buttplug sending back a little message
saying hello from plug. Uh which
means that yes we obviously we just got code execution on the
butt 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 Lovense’s attempt to like,
open up to the- open source
community; it’s possible, it’s unlikely. But the point is
anyone who can connect to your
buttplug at this point can get code execution on it. Uh which
seems kind of dangerous. At this
point we do still require uh being local like being in the
uh- the physical vicinity of the
butt plug to get code execution on it, so that’s probably not as
big a deal as uh, as we’d want
it to be. But it’s still a good question of being like “Ok, we
have code execution on the butt
plug, what can we do with this?” Well there’s a few ideas that I
had. The first 1 is if you can
get code execution on the butt plug, you can actually create
butt plug ransomware. Uh
[laughter] [coughs] 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 r- ransomware you
can ask maybe for like 50 bucks to unlock it and protect it from
future uh butt plug ransomware.
Uh kind of butt plug vaccine if you will. Uh so this is uh 1
scenario that could work.
Another scenario that is kind of interesting but I did not really
look into that much is the idea
of like weaponizing a butt plug or any other sex toy like
physically. Um and you know in
the case of butt plug it really just has 1 motor and uh a little
battery, well like uh a pretty
big battery actually, like I guess probably 80 percent of the
butt plug is a battery. So the
question is you know I don’t know if you remember like what
happened with all these uh
Samsung Galaxy Note phones when they were like just kind of
blowing up [crowd groans] well
it- it might you know possibly be possible to, you
know.[chuckles] [audience
laughs] 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 um I’m gonna assume
that this is not possible but it is something that is worth
thinking about because you do
have actually a lot of other sex toys that have other um- other
things then a motor. Right? Uh
you have sex toys that apparently have- I I was looking
at the code of the app uh and uh
looking at all of the different commands that work for different
sex toys. There’s a command that
it says that just says rotate so clearly there’s some kind of
moving part in this uh sex toy.
Uh and I’m wondering you know maybe, maybe there’s like a
safety feature for that motor
that is actually encoded in the software right? Instead of in
the hardware. So getting code
execution on it could have uh bad consequences. Same thing I
think there’s like another sex
toy that has some kind of uh air pump uh which seems dangerous
but I don’t actually know if it
could be uh problematic. So it’s something that’s worth looking
into. And finally we do have our
last thing which is the hostile butt plug. Hostile in terms not
of you know exploding your butt
but as much as uh kind of trying to hack into your other devices.
Uh so that is something that’s
worth thinking about and that’s what we’re gonna be looking
into, it’s like ok we have code
execution on this, we know we can do inherent ransomware, but
can we start hacking other
devices from our butt plug? Of course the answer is gonna be
yes. But for now I’m gonna
pretend that we don’t know that. So uh interestingly, uh well at
this point we have code
execution on 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 first
thing, so this is like the call
back on the left uh in javascript uh I guess this is
how it works to talk over uh
serial ports in uh in electron app. Uh and what it does is it
gets it N, N is like the
incoming data, uh throws it into uh, well it- it- it casts it to
a string then it throws it to a
bunch of different functions. The first function is find
dongle which basically just
handles uh 1 of the initialization messages that
comes from the dongle. Uh the
second 1 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, uh it’s kind of come up in just a few minutes. Um so it
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
circumpair 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 call
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 that error um
function. Uh so it prints it out
to uh to console as uh- as an error messages for some reason.
But what it also does is it
creates a new DOM eh- element, like an HTML element, and it
throws the entire contents that
it just received over serial into that element as HTML. Uh
now I’m not a web dev but if you
are you will probably think that this is a massive uh cross side
scripting vulnerability from a
butt plug dongle. Uh so from there basically, if you have
control of the dongle and you
can send anything over uh 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 in an
electron app uh basically is
just yeah it just compromises the computer because there’s no
sandboxing 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. 1 of the uh ways of doing
it is what I was showing on the on- on the right up there. Uh
you have an- 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 they, uh whenever it can’t actually be
loaded. And so the screen shot
is just showing that plugging in this malicious dongle is going
to allow you to uh execute
javascript code in the app. So that’s problematic. Uh it’’s
kind of annoying to get a huge
payload just because of um of the fact that we can only do 32
characters at a time, but it’s
entirely possible. So at this point we’ve actually compromised
the app from the USB dongle. So
we’re halfway there to kind of making it back to- from from our
butt plug to the app which is
pretty cool. Uh. 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 butt 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 butt plug directly.
Unfortunately the answer to that
is no and the reason is that we have another uh character length
limitation on the messages that
are coming from uh- from the butt plug to the toy- 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- the dongle firmware. What it does is it just grabs incoming
data, if it sees that it’s more
than 20 characters it just kind of cuts it there and copy pa- uh
copies it into the new buffer.
Now a new buffer is actually on the stack. And uh 1 of the,
there’s actually a vulnerability
there which is that they don’t uh null terminate the- that-
that string. So if you’re able
to place some uninitialized data after the string, you can
actually send more than 20
characters up to the- up to the app. Uh unfortunately I did not
find a way to actually exploit
this but it is uh it is a kind of vulnerability so it’s it’s
worth keeping in mind. [coughs]
So uh problem here is yeah we can’t actually use this to get
code execution directly on the
app from the butt plug. Which is kinda sad. But- uh well it’s
kinda sad for 1 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 uh uh- any kind of
um of uh you know uh memory
corruption vulnerabilities in the actual butt plug specific
code. However uh the 1 thing
that’s pretty cool is that there’s way more code on this
microcontroller then just the
butt plug specific code that was written by Lovense. There’s also
this whole uh soft device region
which is at the bottom of memory. It’s uh it’s based at 0.
Uh and so what this soft device
is is basically a driver for that SoC that was written by uh
Nordic Semiconductors
themselves. And so it’s going to contain everything that you need
to interface uh- 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’s 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-
uh Bluetooth low energy stack. That’s just what we did, uh in
order to hack a butt plug we
were finding bluetooth vulnerabilities. Um and uh and
yeah so so because we- we can
kind of debug it- um debug that the- buttplug or or the- the
dongle firmware, it’s actually
really easy to ju- kind of just like follow uh the flow of data
because there’s also no SLR and
then it’s really easy to define the code that is going to be uh
handling those message. Uh and
on the right here we actually have 1 of those functions that
handles these incoming messages
um for the uh general attribute protocol. Um for for central
mode uh messages I guess. Um and
so uh what- what I’m showing specifically is actually uh the
uh handler for um for 1 of the
uh- very uh- 1 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 it
a certain type and then it’s
going to return all the handles for all the attribute choices
that are eh- 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 1 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 uh attribute data, and that fixed length buffer is going to
uh have- be instruct basically
that has just the handle value and then a pointer to the data
associated with that handle. So
that’s what you can kinda see with these uh little arrows
there is that- I can actually
yep. Uh oops. If you – you have these little arrows there is
that you- you can have in- at
the bottom left there uh that’s the actual binary like hex data
that is inside of that buffer.
And so you have the uh the uh 0XD handle and then a pointer
that points to that data like
the data in blue that’s associated with it. And then 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 needed to be said. So vulnerability here, uh
if you read the code a little
bit what you’re going to see is that yeah, it reads that little
uh purple field uh length field
from the uh from the incoming message so that’s completely
controlled by a potential
attacker, and if we look at what happens if we place uh value 0
there, basically you end up with
an un- unbounded uh infinite loop. Uh so that loop is- sorry.
Because it’s unbounded it
doesn’t actually check that the- the data it’s writing into the
output buffer is within the
output buffer. We have a very uh classic uh stacks match kind of
vulnerability which obviously is
very unfortunate because on these devices once you can smash
the stack because there’s no
stacker keys or you know ASLR or DEP or anything, you basically
immediately have code execution.
In this case the problem is uh because you have uh value 0
there uh in this specific case
it’s actually going to be in completely infinite loop. So
you’re just going to overwrite
all the data in ram with garbage. Uh which is kind of
unfortunate because that’s
definitely gonna crash and not gonna be useful. But if you
think about using value 1 it
actually is going to be bounded by the number of bytes that are
inside of the incoming message.
And what that means is that you’re going to be able to uh
overflow ever so slightly from
that buffer, and uh then from there uh because the stack- uh
buff um buffer that is based on
the stack, going to be able to corrupt uh everything that’s
near it. So taking a look at
before uh wha- what happens when you do actually use this uh
overflow on the stack. In yellow
is going to be the attribute buffer that I was mentioning,
then in blue is going to be a
bunch of save registers, and uh orange is actually the return
address. So that’s kind of the
things that you would kinda be um corrupting on the stack. And
then you run this um run the
vulnerability, it’s going to overwrite all this data on the
stack with uh in this case
completely well- it’s going to write 2 things right it’s going
to write the handle data which
is actually only overwriting the l- the l- lower uh the l- less
significant bytes of uh of um of
D words every uh 8 bytes. And it’s going to be writing a bunch
of pointers to data that we
control. So it’s 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 a 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 pa- packet if you think
about it. It’s going to just execute a piece of code you give
it without really doing a lot of
fuss which- which is pretty cool. Um thing is uh you know
the Corex- the Cortex MO 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 1
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 there’s
like actually uh like local variables that we’re overwriting
on the way over that are used on
the return path of this function. Uh 1 of them
specifically is actually uh used
to be dereferenced at a 32 bi- bit binary- uh boundary. Uh and
so what happens is that 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 gonna
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- SoftDevice allocates
these incoming packets is in some kind of ring buffer with
absolutely no um uh enforcements
of any kind of alignment uh requirements uh and so what that
means is that if I send a packet
of a certain length before or after, I can control the
alignments of this packet that
I’m going to be sending afterwards. So this is what
you’re kinda seeing in- in
yellow and in blue are 2 packets are being sent before the uh
exploit packet is 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, the way that’s
useful and not just you know uh
exploiting well not just executing to uh- 2 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 the data, uh both of these are gonna be
used by the shellcode. And then
a third packet which is going to be the 1 that actually triggers
a vulnerability. Uh the way that
it works is that the 1 that triggers the vulnerability is
going to exploit- execute a
single instruction which is what you see that C1 uh E7
instruction there. Uh what that
does is it jumps back into the green uh allocation into the
green packet, uh and then that 1
is going to execute this very simple piece of code which is-
lo- loads a bunch of registers
from the uh- I think the blue packet. And then it’s going to
uh use that to call in to a
function, return cleanly, and then we can just send that
packet over again. So that
allows me to basically by sending 4 packets execute any
arbitrary tiny piece of code
within that uh [coughs] 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
memcpy and uh over and over and do that to copy a larger
shellcode binary and then we’re
gonna jump into it and that allows us to execute a lot more
code. So at this point we
actually just have completely compromised this, we just need
to write the shellcode. And so
because we want our uh compromise to be um permanent,
basically we’re just going to
write a little piece of shellcode that’s going to
overwrite a piece of flash, uh
let us hook- hook into the uh original dongle code and uh
start sending uh you know the
serial data that we were talking about earlier. So this 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. With
our control over a buttplug 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 uh 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
SoftDevice uh yeah on that SoC uh which is basically everything
that uses that SoC and
apparently there are a lot of devices that use this old uh NRF
uh 5 1 8 2 2. So we have
essentially found a vulnerability that could also be
used to compromise every one of
those- those devices, assuming that it’s configured in a- in a
proper way. Or like a way that
is you know uh 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-
it’s the world we do live in at this point. So the question is
uh we have the ability to
compromise an app from the butt plug. What can we do with that?
Uh well this is um you know we-
we’re still just executing javascript inside of uh the
Lovense uh electron app, the
question is what does that give us? Uh because it’s Lovenese and
that this is running at a Medium
IL on Windows it turns out it actually just gives us kind of
everything. We can access all
the- all the files on the- on the file- on- on the computer,
we can execute arbitrary code,
uh just spawn uh any XC that- that we want. Um so we’ve
basically kind of compromised
the- the computer just by uh by doing this. Um which is you know
kinda 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 kinda viral right? Because technically
we can already compromise a butt
plug from a different butt plug, or from a different uh uh you
know dongle and that could be
something that we- could be used like you know uh kinda spread
this locally but it would be
better if we could spread it over the internet because you
know obviously that would be uh
much more people that you can reach. Now the question is uh
how do we do that? Well there
are a lot of these uh social features on the app uh such as
the chat based uh stuff and the
fact that you can just kinda remotely control a toy. Um so
the question is how does that
interface work? Uh does that allow us to kinda compromise the
remote device? Of course the
answer is gonna be yes, but how does it work? Uh basically uh
well it’s that’s what was
showing at the- at the bottom left there is uh a JSON object
that is used to control the-
the- the device remotely. Uh it’s going to have kind of like
the type of object it’s supposed
to be and then in the- this ID mode is going to give the um-
the mac address of the butt plug
that is supposed to be g- controlled as well as the
command so V means vibrate, uh
and um and that’s what’s going to be sent over as JSON to uh-
to the remote app. Now, how does
the remote app kinda use this? Uh the thing that we can kinda
think about here is that
basically if we’re able to somehow hijack this into
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 execution there, and then use that to kinda get code
execution back on the app. Uh so
it’s kinda 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 bott- uh at the top uh in the ID mode uh it does check
that N which is the incoming uh
vibration uh you know strength data is greater quantities than
0. 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 0 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 gonna work. So that’s gonna
block us. That’s what makes it
such so 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 in 0, it’s checking that N is not uh
less than 0. And the problem
there is, well, if you check that it’s not less than 0 then
yes the string is also gonna
tell you that is- that is- it is not less than 0 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 comp- compromise the
dongle for the uh JSON parser.
So basically the only difference here is that we can just do it
over the internet uh basically
exploit this firmware bug over the internet just because they
you know flipped a uh a check
which is unfortunate. Uh so at this point you know we have
actually our viral uh butt 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 con- control our toy.
Uh but uh turns out you can actually get code execution off
the remote app in a much simpler
way which is that they have uh a chat uh feature where you can
send texts. 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. [laughter] 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 code execution just by sending a
message. Uh so we basically
achieved our goal. Uh this is the payload I ended up using, uh
it’s going to both uh you know
spawn a local process to get code 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 a uh,
basically a uh a completely viral uh you know exploit here.
So we’ve compromised every node
of the network, which is what I wanted to do. So uh you know
yay! Go us! [laughs] And that
means that it’s time for a live demo! [audience cheers] A little
tired of trying to remember how
all of this all works. Uh yeah you can all see this. So uh
please bare with me. Uh so first
thing that I’m gonna show you is uh this I’m gonna 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. Ok. So this VM is just a regular Windows VM
it’s connected to the dongle uh
because VM ware lets you do that. And I’m gonna turn on this
butt plug. I hope you can hear
it. [plug vibrates] [crowd laughs] Um so this works, it’s
on, then you can kind of add a
toy, hopefully that’s gonna work as well. [crowd chuckles] Oh
wait, sh*t I forgot to do
something. [laughs] Ok. Let’s start over. Ok so disconnect
that’s cool but uh it didn’t, I-
I’m a dumb*ss. Come on. [sniffs] So I actually want to disconnect
this because I forgot to uh
start the BTLE jack process on that same uh side. Uh the only
reason that we’re doing BTLE
jack in this mode is that it’s gonna be uh more successful uh
for a live demo, but in theory
well I mean not just in theory actually in practice, you can
also hijack an existing
connection without having to sniff it while it’s happening.
So this is just to make things
easier. Ok so now we’re gonna do this again. Connect the toy.
Hopefully the sniffers are going
to detect that connection, alright it detected a connection
on the left there. That’s pretty
good. Ok 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. But it’s there.
[laughter] Gonna stop it. Ok.
Alright it’s stopped. From here we should be able to actually
hijack this connection. Uh the
way we do that is- I’m trying to remember this. Oh my god. I used
to have a mouse for this, it was
much easier. Ok then we copy this parameter. I’m ss- really
sorry about this um- gonna try
and make it faster. Alright and T which means hijack. So we’re
gonna try and hijack this
connection here. And if it works it should uh kill the connection
to this app and just- it should
just happen. Ok 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 over
the buttplug from ubuntu uh and
so in theory we should be able to make it uh for example,
vibrate remotely. Uh no STR
vibrate 20 is, oh not cibrate, god d*mn it. Uh 20. Uh oh it’s
it’s actually happening there.
Uh so- so that works, that’s great. [applause] Now we’re
gonna put this into DFU mode,
hopefully that also works it should stop it if it works.
There we go. It stopped. Okay so
now it’s actually in firmware update mode so at this point I
take my phone, I’m gonna 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
you’re gonna grab the firmware
version uh for the exploit, version 27 that’s a lot of work.
Uh and we should be able to say
DFU Targ, ok so now we’re gonna be flashing this new firmware
from our phone. Uh it’s
updating. Eh. Gonna just keep this here for now. And from here
uh what we’re gonna 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 it’s own, let’s
see. [laughs] And so [crowd
laughs and applauds] So this worked uh at this point we have
gotten code execution on the
dongle and then back on the computer through this we
downloaded an 0XE from the
internet and we ran it uh. It unfortunately encrypted our butt
plug which uh [laughter] you
know is unfortunate. Uh it’s probably from North Korea
[laughter]. And then what we can
see is that I had this other uh VM which was also running the
app, this 1 is not connected to
a dongle or anything as you can tell, uh but it is connected to
the internet. And it is like my
friend. Uh and so [crowd laughs] 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 wanna like you know um get your butt plug
en- encrypted. [crowd laughs] Um
and and yeah that’s- that’s basically it. Uh the conclusion.
Well ok. I think there’s a
couple lessons that we can learn from this um which is you know
as I mentioned you know as- as
much as this is kind of like a funny line of research, uh in my
opinion it is actually kind of
important to uh look at the security posture of the- of
these devices; not only because
it is actually used by people for their livelihoods but also
because in my opinion it is kind
of uh uh very representative of the current state of you know
IoT and connected devices in
general. It’s kind of like all these different technologies
which are both new and not new
uh kind of like working together and people don’t necessarily
understand all the implications
of like having 1 vulnerability in 1 there in 1 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 uh 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 wanna find
all the code uh that was uh in
there uh go follow me on Twitter. I’m gonna post this on
GitHub uh later today if you
want to start hacking your own butt plugs. And I want- 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 extremeley gay. Uh I’m not gonna name names
but you know who you are, Aaron.
[laughter] Uh hah. Thank you very much. [applause]