Analysts believe that there are currently about 10 billion devices from the Internet of Things (IoT) world. Sometimes these devices gain their place in the market, literally climbing up human asses. As it turned out, cheap and low-power radio chips are not only great for home automation - they also change the way people interact with sex toys. In this report, we will plunge into the world of television dildonics, the technology of sex at a distance in which tactile, temperature and other sensations are transmitted between partners through a two-way communication line. The speaker will tell you that the safety of Buttplug electronic electronic anal sex toys can be opposed to an attacker who finds and exploits vulnerabilities at each level of the stack. Ultimately, this allows the sextoys themselves to be compromised,and the devices to which they connect.
A hacker with the nickname smea, or Smealum, began his career as a developer of video games for such game consoles as Nintendo DS, simultaneously trying to crack them. At some point, the consoles acquired serious security systems, and Smea switched from home-grown software to developing techniques for breaking it. Smea is known for its “work” on Nintendo 3DS and Wii U, although it also contributed to the development of exploits for the most popular web browsers and virtualization stacks. Probably, now he became interested in breaking into “smart” anal plugs.DEFCON 27 Conference. Buttplug: True Penetration Testing. Part 1
Of course, you can manage incoming messages even with such a short line length. For example, 30 characters is enough to execute malicious JavaScript. This slide shows an example tag with a length of 30 characters for an image from a non-existent source <img src = a onerror = 'alert (1)'>, which causes the application to display an error message. This message will be displayed whenever image loading is truly impossible. The screenshot shows that connecting through a compromised dongle allows you to execute malicious JavaScript.
The 32 character limit is annoying because it’s hard to realize the volume payload, but it’s quite possible. So, you see that we have successfully compromised the application using a USB key and are now halfway to reverse hacking, that is, to compromise the application using a hacker bootplag. Hacking on a dongle-computer site can occur in two ways: through a computer, you can compromise a dongle, and through a dongle, you can compromise a computer.The dongle acts as a small bridge between the boot plug and the application. The question arises: is it possible to use the same vulnerability to compromise an application on a computer directly through the bootplag. Unfortunately, the answer to this question is negative, and the reason is that there is another limitation on the length of the message characters that come from the boot plug-in to the application.
The dongle simply packs the messages of the boot plug-in and sends them to the application, and at this step you can insert your HTML code into them. However, at a time it can receive a message no longer than 20 bytes long, which is not enough to carry out an XSS attack. However, there is a bug in the dongle firmware: there is no check for the null terminator at the end of the line. Therefore, if you can place some uninitialized data after the end of a 20-character string, then you will be able to send the application more than 20 characters. Unfortunately, I did not find a way to use this vulnerability in practice, but such an opportunity is worth keeping in mind.So the problem is that you probably cannot use this vulnerability to force the application to execute code received directly from the boot plug-in. It is sad, but even sadder that if you look at the dongle firmware, you can see that in principle it does nothing with the received data, but simply copies them to a new line and sends it further. Therefore, we will not be able to use its vulnerability to attack by way of overflowing the memory buffer. However, if it is impossible to hack the application directly from the boot plug-in, perhaps it will be possible to do this through the boot plug-dongle-computer chain?The good thing is that the dongle chip allows you to place much more code than is required for the original Lovense Hush developer program.
The dongle’s flash memory contains an area reserved for the DFU loader, an area for the Lovense application itself, and a closed SoftDevice area for the hardware driver for the Nordic Semiconductor BLE chip. This is where the BLE protocol itself is processed. For example, when an application wants to send a BLE message to a toy, it accesses SoftDevice through an SVC call. In addition to these 3 areas, the dongle has an unused area of flash memory of a sufficiently large volume.To find the vulnerability in the BLE SoftDevice stack, you need to use reverse engineering, since it is not open-source. I did the same in order to find the vulnerability of the firmware plug-in. In this case, it’s very easy to follow the data flow, because there is no ASLR there either, and it is easy to determine the code that will process these messages.
On the right on the slide, you see the GATTC incoming packet handler (a profile of common attributes), which, in essence, is a dongle. In particular, it is a read handler by type of response packets. I am not a specialist in Bluetooth devices, but I think that the point here is that the dongle reads the type of peripheral device and uses handlers for all variants of the attributes associated with this type. This means that in fact you can get more than 1 attribute at a time, and the size of each handler of a pair of attribute data is encoded as a field inside the package, which allows you to manage them.
The slide shows a sample of such a package. GATT clients can send a read by type request packet that contains the type and range of descriptors to read. Servers that respond to the read by type request return data associated with the handlers within the range corresponding to this type. The number of descriptor / data pairs is determined by dividing the length of the remaining packet by the field length of the descriptor / data pair, and this field is always 0x7 or 0x15.
The slide shows the operation of the function we are interested in: you see how the packet is filled with data from an array of attributes, and a fixed buffer length is allocated for them. This is where the descriptor value is placed, and then the pointer associated with it. An attribute array is binary data that is placed inside the buffer in hexadecimal format. The data is highlighted in blue, and next to it is the 0D descriptor and its associated pointer 00, it is highlighted in orange. The package of the second and third handler looks similar.The vulnerability is as follows. If you read the code on the right, you can see the attribute_data_length parameter placed in the purple frame - the length of the incoming message, the value of which is completely controlled by a potential attacker. If we place a zero value there, we get an infinite loop.
The loop becomes infinite because the code does not check whether the data that it writes to the output buffer is inside this output buffer. As a result, we get a classic stack buffer overflow, since the device does not have ASLR or DEP, and the code immediately executes.Assigning a value of zero and getting an infinite loop, you actually replace all RAM data with garbage. However, this is an unsuccessful solution, as it is likely to cause a device failure. But if you use a value of 1, then it will limit the number of bytes that are inside the incoming message. This means the following - you can slightly overfill this buffer, and then the buffer, which is based on the stack, will be able to damage everything that is next to it.
Let's see what the stack looks like before overflow. The array of buffer attributes that we talked about is highlighted in yellow, the saved registers in blue, and the return address in orange. By setting the attribute length to 0x01, we can cause an overflow of many handle / data pointer pairs. Descriptors consist of 2 bytes, but the top two bytes of the DWORD descriptor are not cleared. The buffer that we are overflowing is on the stack with no cookies, no ASLR, no DEP.
Next, we test the system: send a packet full of 0xDA bytes with an attribute length of 0x01. It turns out that we rewrite the return address with a pointer to our attribute data. Since there is no DEP, this means that each time the function returns, the code that is inside our package will be executed. The only limitation is that we need the return address to have the LSB set to the least significant bit, so the code runs in Thumb mode, because the Cortex M0 processor does not support ARM mode.
We also rewrite several local variables, while making sure that we do not rewrite anything used on the way back. Basically, we get a classic backdoor package. If you pay attention to this stack, you will see that the rewritten one does not correspond to the border, which will cause the program to crash.There is another requirement regarding stored registers. These are local variables that are also overwritten when the function returns.
One of them is used to dereference a 32-bit border, and content mismatch with the border will cause the program to crash. Therefore, you need to make sure that saved_arg_3 = 0, saved_arg_4 corresponds to DWORD, that is, it is within the border, and LSB is set.Therefore, we need to make sure that this package is working. Fortunately, this is really easy, because the way SoftDevice distributes these incoming packets is a ring buffer without any forced alignment requirements. Whiteshark made it possible to verify that the alignment of the subsequent packet can be controlled by changing the length of the previous packet.
Yellow and blue highlighted 2 packages that are sent before the exploit package is sent. This allows me to control the alignment of the last package and make it so that it does not cause a program crash, which is what we are aiming for.I note that there is a certain engineering obstacle: Nordic SoftDevice does not provide an interface for sending raw BLE packets. To circumvent it, you can use 2 options: implement your own BLE stack or crack some hooks in the original packages. Since I am lazy, I chose option 2.These hooks are quite simple, but require some reverse engineering. Hacking methods can be found on github, the interface is quite “dirty” and there are no guarantees that this will work, but I did it. You are still better off using BTLEJack.void ble_outgoing_hook(uint8_t* buffer, uint8_t length);
This SoftDevice pointer is called whenever a BLE packet is sent, so it can be modified in advance:int ble_incoming_hook(uint8_t* buffer, uint16_t length);
This hook SoftDevice calls whenever a BLE packet is received. The return value determines whether normal SoftDevice processing should be skipped.int send_packet(void* handle, void* buffer, uint16_t length);
This is how the function of sending the raw packet to this BLE connection looks like.How can I process more than 4 bytes of code at a time? Need to send some packages! On the right you see the ring buffer of incoming BLE packets. The first packet is shown in green: the shell code that executes a function call with controlled parameters and then returns “clean”. The second packet is shown in yellow - this is a data buffer that can be used by a function call. The third packet is shown in blue — a buffer containing the values of the function call parameters, and orange — the packet that launches the vulnerability using instruction C1 E7.
After returning the pure function, we can resend this package. Sending these 4 packets executes any arbitrary piece of code inside the dongle, and this can be done over and over again.
This is convenient because in this way I can really just call memcpy several times to copy the larger shell code binary into RAM. Then we call this function to patch the original dongle code in memory, and use it to compromise the application installed on the computer. Since the XSS payload is large, we do not send it, but generate it in the shell code on the dongle itself. The shell code is as follows.
As a result of these manipulations, the following is obtained: if we can control the application, then we can control the dongle and the bootplag.
There are 2 ways of hacking on the buttplag-dongle section: the dongle can compromise the toy, and the buttplag can compromise both the dongle and the computer. The bonus is that the Nordic BLE vulnerability is present not only in Lovense products, but also in any devices that use SoftDevise S110, S120 or S130 for the client side of BLE.So, we have the opportunity to compromise the application using the bootplag. How can this be used? We are still just executing JavaScript code inside the Lovense application, and the question is, what does this give us? It turns out that the lovense.exe application runs on Medium IL and runs on Windows, it offers truly unlimited possibilities: even without administrator privileges, you can access files on your computer, you can execute arbitrary code, you can implement XSS, access the network etc.
The next question: if you can create a ransomware program that not only infects the bootplag, but also the user's computer, is there a way to spread it further by making it viral? Now we have a hack at the local level, but for a hacker it would be much more useful to gain control over many user computers via the Internet. How do we do this? The social functions of the toy, such as video chat, text chat, image transfer and the remote control itself, significantly expand the attack surface.Remote control is an excellent goal, because if a developer wants to use a proprietary program, it will definitely have bugs and vulnerabilities. How to use it? For example, you can send a partner a JSON object containing commands, for example, the command “Vibrate: 10”:{
cate: "id",
id: {
DEADBABEBEEF: {
v: 10
}
}
}
In this case, the receiver analyzes the incoming JSON, generates a command for the toy and sends it further, and here there are 2 modes. The first mode "id:" sends a command to one specific sex toy, the second mode "all:" sends a command to all remote toys.Are incoming data validated correctly? Since JSON is very flexible, the code, expecting a number, can get an entire string instead. If we can control the commands sent to the toy, then we can probably use the dongle parser bug. On the next slide, the orange frame shows where the input data is used, and the blue one shows where it is checked.This bug is that the application does not properly check that the input for a command such as vibrate is actually an integer. In this case, in the "id:" mode, only that the vibration intensity index is n> = 0 is checked, and if you pass an integer 12 that is greater than zero, this parameter will pass the test. Even if you pass a string, that is, the number in quotation marks “12”, the system will accept it. It will not accept only a string in the form of a combination of numbers and letters, for example, “12test”.
As you can see, this check does not allow us to enter a text command. However, if you look at the bottom of the code, you will see the same check, only this time the application checks the condition n <0. Now, if we enter “12test”, then we won’t pass the test, because the application will consider that the given expression as a string is not less than 0. But if we enter a string with an inequality check of the form! (“12test” <0), the system will consider it true , despite the fact that this is not an integer and not a number at all, but an alphanumeric combination. In essence, this means that we can enter in this command an arbitrary string that will be sent to the dongle. This allows us to send the exploit code in the same way as we did before to compromise the dongle through the JSON parser. The only difference is that now it can be done via the Internet.
So, thanks to a bug in the implementation of the filter for checking incoming data, we got the opportunity to remotely compromise the dongle through the Lovense application, through which, in turn, we can crack the user's computer. Hacking a dongle is a great thing, but the condition for success is the consent of the partner to transfer remote control over the toy to the disguised attacker. This is convenient for a targeted attack, but completely unsuitable for a viral one.However, text chat and pictures do not require any permissions, which perfectly allows for a classic XSS attack by sending malicious HTML code in a chat text message. Distributing the virus becomes trivial: just create the right JavaScript function and spam your friends.
At this stage, we can execute the code only by sending a message and basically achieved our goal. The final XSS payload works like this:- Do everything that should happen on the victim’s machine.
- Grab a JavaScript object that allows you to access the chat.
- Send an XSS payload that downloads this script to the computers of all your friends.
Thus, we compromised every node of the network from the boot plug-in to the Internet. Now you can compromise any device from any device - we created a butt worm, or a virus called "ass worm."
As I promised, now I will show you a live video. The first thing I will show is using the BTLE jack to intercept the connection between the boot plug-in and the regular Windows virtual machine that the dongle is connected to. Now I'll try to turn on the bootplag - I hope you all hear the sounds of vibration! (laughter). So, it worked, now I’ll try to add my toy to the application control panel. See that the program found Hush, but wait a minute! I forgot to start the BTLE jack process. The only reason you need to use the BTLE jack in this mode is because it makes the live demo easier, but in practice, you can intercept an existing connection without the need for sniffing. So I'm launching this thing just to simplify the experiment. Let's repeat all over again. You see that the connection to the toy is established.
The sniffer on the left shows that it found this connection. So, we have an application that is associated with our sex toy. I don’t know if you hear that I really can control the boot plug-in (smea moves the slider up, after which an amplifying sound of vibration is heard). Now I turn off this thing (moves the slider down, the sound of vibration disappears). Now I need to hack this connection. To do this, I copy several parameters, paste them into the smea @ ubuntu line and at the end I enter the t parameter - a command to intercept the connection.
If this works, then it will kill the connection with the application. As you can see, a message appeared in the application window that the connection with the device was lost. Thanks BTLE jack for a great tool! The bootlog disconnected from the application and is now controlled through the ubuntu virtual machine. Theoretically, we should be able to remotely make it vibrate. I type the Vibrate 20 team, and as you can see, everything works - we were able to remotely control the bootplag without the help of the official application (applause from the audience). Now I'm going to put it in DFU mode, and if that works, then I will have to stop this thing. I enter the appropriate command and the vibration stops.
Now I take my smartphone and check if I can reconnect the toy through the application. Among my applications, I find the update of the firmware plug-in and select the target DfuTarg - the device on which it is necessary to update the firmware, but in fact - introduce a malicious exploit into it.
You see how the update process goes. A message appears on the screen that the device firmware has been updated successfully. Now I will try again to connect the bootplag to the application installed on my computer, and you can see what happens: a ransomware screensaver appears on the screen (applause from the audience)!
“Oops, your butt plug is encrypted! Pay for the restoration of access to this important toy with $ 50 bitcoins within 3 days, otherwise in a week you will lose it forever. ” Here's how it works!So, you executed the code on the dongle, then on the computer and via the Internet got to the boot plug. As you can see, in terms of security, this butt plug is very weak, probably it was made by North Korea. You saw that I had a virtual machine installed that ran the application without being connected to a dongle or other hardware. This VM was just connected to the Internet and seemed to be connected to my friend’s computer. So we have successfully achieved the viral spread of the ransomware.I think that from all that has been said, a couple of useful lessons can be learned. Using this device as an example, we examined how vulnerable the world of the Internet of things can be. Some devices are used for life support, and people do not realize how vulnerable these new technologies are. Hacking one “smart” thing, you can hook up other “smart” devices in your home via the Internet. I hope that the result of my research is applicable not only to sex toys. Also, I intend to learn all the code for this thing, so join me on Twitter. I’m also going to publish my tools on GitHub today in case you want to start hacking your own bootloops.
I want to thank all my friends who helped me in the pentesting and introduced me to the world of battle plugs, being extreme gays. I won’t give names, but Aaron, you yourself know who you are (laughter). Thanks guys, that was awesome!A bit of advertising :)
Thank you for staying with us. Do you like our articles? Want to see more interesting materials? Support us by placing an order or recommending to your friends, cloud VPS for developers from $ 4.99 , a unique analog of entry-level servers that was invented by us for you: The whole truth about VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps from $ 19 or how to divide the server? (options are available with RAID1 and RAID10, up to 24 cores and up to 40GB DDR4).Dell R730xd 2 times cheaper at the Equinix Tier IV data center in Amsterdam? Only we have 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV from $ 199 in the Netherlands!Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - from $ 99! Read about How to Build Infrastructure Bldg. class c using Dell R730xd E5-2650 v4 servers costing 9,000 euros for a penny?