Locked In An Insecure Cage

Locked In An Insecure Cage

In this research, it helps to have an open mind and to not be judgemental.  While we make sure to take strides to avoid making judgements about the users of IoD devices, we sometimes have to make judgements about the vendors based on their actions and communications with us.  We generally try to be forgiving and assume ignorance of security best practices versus indifference or, at worst, malice on the part of the company.  So far, most have woken up to the fact that they are ultimatley a software company and as such, they have a responsibility to their customers. Sometimes it takes a nudge, but most get it very quickly and understand that not looking after their users safety, privacy and security will ultimatly hurt their business. Some however haven'nt taken this to heart and despite many concerned researchers efforts, they resist efforts to do what is necessary to prevent harm to their customers.

QIUI is the company behind the CellMate chastity cage, a bluetooth enabled device that fits around the genitals and is controlled via mobile app.  Control can be local via the app or control can be given to another user who can control and lock/unlock the device via a back end API that the app interfaces with over the internet.  It should be noted that it was discovered that the device can only be unlocked by the app. There is no mechanical bypass or physical key.

I had been aware of the Cellmate device for almost a year previous but had yet to do any thourough anaysis on it and had only done cursory looks at their app and API.  What I saw was not comforting, however life gets in the way and I never got the chance to do a deeper dive, nor came across an opportunity to purchase the devices for proper testing.

In May 2020, I (RenderMan) was contacted by a developer, @MikeTsenatek who had obtained one of these devices and had taken a look at their app and API and quickly found some very alarming things.  As they were not a security researcher, they were unsure of how to reach out to the company and how to communicate the vulnerabilities they discovered to them.  Initial contact through their public contact forms recieved no replies.  Additionally, they wanted to remain anonymous, so they reached out to me for help and I was happy to act as a proxy to get these issues reported (this is one function of the project I'd like to see happen more often)

In short, pretty much all data in their database was accessible via the API. This data was unencrypted and required no authentication to access. The API disclosed personally identifying information (PII), usernames, passwords in cleartext, email addresses, gender, phone numbers, platform 'friends', and more.  It was even possible to find a users recorded GPS location that was stored in the database.

After some discussion, I was given their findings and was able to verify all of them myself.  Contact was made via email with the company's CEO, Jake Guo, and they were provided with a lightly edited version (mostly fixing font related issues with proof-of-concepts and expanding explanations) of the researchers report detailing all the vulnerabilities the researcher discovered on May 17th, 2020 .

After a lengthy period of time, some of the API vulnerabilities were fixed and a new version (Version 2) of the API and app was released.  While many issues that had been reported had been fixed, many  issues still remained and new ones discovered.  Additionally, the original version 1 of the API still remains accessible which undermined the point of a new and improved API when the same information was available through the insecure API.

At this point, the last communication we had was May 19th, 2020, two days after the report was sent to them. They acknowledged and thanked us for the report, and then....Nothing.

The new API was released sometime in June but nothing was communicated to us to let us know this happened. It was noticed when we were checking up on their progress by retesting the vulnerabilities out of boredom and curiosity, and not because we were informed.

Throughout the summer, I pinged the CEO and a few other staff at the company but received no response. This pattern repeated itself several times until September. No response.

On September 11th, 2020, I happened to see a tweet by @AlexLomas, a researcher at PenTest Partners  (a company with whom I've dealt with before and to their credit, now treat IoD devices and research with the respect it deserves) that described frustrations reporting an IoD vulnerability that sounded very familiar.

"Only my opinion (and would genuinely love to hear dissenting voices) but dating apps and teledildonics should be right up there with healthcare and banking when it comes to protecting user’s information."
"I have had some really good disclosures on dating apps (Recon last year were great). But I have a current teledildonics episode that is making me lose my remaining hair. So so bad."

This made my hair stand on end because it sounded a lot like the frustration I was feeling.  I DM'd Alex and just flat out asked if it was QIUI he was talking about and he confirmed.  They had been trying to reach out several weeks before I did and came across the same vulnerabilities and more.  They had gone as far as having native Chinese speakers translate their messages in order to ensure that they were understood.

This was a game changer since the company was seemingly ignoring multiple researchers.  It also confirmed that since more than one researcher had found these issues, more were certainly likely and so the last thing QIUI should do is drag their feet.

At that point, we decided to combine forces, like some sort of Voltron of Sex Toy research (There's an image we need to have someone make)  and present a united message to the company to at least open communication with us and let us know their plans and schedual to fix the issues we'd found.  We also could coordinate and not step on one another as has happened in the past

This took on a new level of urgency since they were launching a pair of new bluetooth and app enabled products; An anal chastity plug and a shock collar.  The anal plug is of concern since it is quite obviously based on the design of the Pear of Anguish, a medieval torture device.  The possibility, depending on it's design, that an attacker could cause serious harm was certainly apparent.  The shock collar had obvious concerns, especially if an attacker could control it via API and override any safety mechanisms implemented in software.  Knowing what we knew about their API and security issues, we were obviously terrified and wanted to ensure any potential harm stayed theoretical.

PenTest Partners has their own blog entry detailing their experiences and their research which is far more complete than our own (the project doesn't have a device to test with and time has been needed elsewhere in this delightful year of 2020). I highly recommend you read their account as well.

In the end, QIUI seems to have sped up development of their version 3 of the app and API. This is likely to incorporate support for the new products, but it does seem to have improved security. This is only based on beta versions we obtained and is not the final release.  Analysis is ongoing and issues reported. If issues are not responded to and acted upon, I'm sure there will be an update here, and on PenTest Partners site as well.

One major concern is that, while the version 3 of the app and API is being developed and readied for release, the insecure version 1 of the API seems to still be available.  We understand that it may be needed for users with older versions of the app that haven't upgraded to version 2 for whatever reason and lock them out of their devices (pun intended), but these are the sorts of things you need to think about with these devices, lest these design decisions come back to haunt you.

So in conclusion, QIUI has grudgingly taken steps to improve security, but only after more than 6 months of constant nagging and a not insignificant effort by multiple researchers. Even then communication has been minimal and not very helpful.

The larger point of this experience that you as a reader should draw, is that this is not how a company should be handling security issues being reported in good faith. Especially when those issues are regarding the disclosure of personal information and potential account takeover of devices that could cause serious harm.

I encourage all IoD device vendors to read through the site and especially the section for vendors about how to setup a vulnerability disclosure program and how to handle reports.  It's not difficult, it just needs to be thought of and implemented before reports come in so you're prepared and seen being responsible about safety, privacy and security which is something that never looks bad.

A short version of what a vulnerability disclosure program should have:

  • Have a 'security@' email address that is actively monitored by technical people in your company
  • Have a policy to review and triage any vulnerabilities reported within a certain timeframe (72 hours is common)
  • Ensure the security contact email and policy are available on your website where people would logically find it if they were looking for it
  • Actively communicate with the researcher about the status of your review and triage, any expectations (both from the company and from them), and if any further information is needed
  • Don't involve lawyers, NDA's or threats to sue. They are your customer as well and are basically giving you free labour
  • If their finding is legitimate, keep them apprised of the status of the fix and any timelines. Often they are more than happy to re-test and verify fixes
  • Credit where credit is due. Consider a public thank you somewhere. Allow and even encourage the researcher to publish their discovery
  • Understand that mistakes, bugs and vulnerabilities can happen. How you respond says more about your company than anything

While we at the IoD project don't generally recommend or discourage purchasing any particular product.  We just try to make them better by providing oversight.  In this case, it seems that that oversight was not well received and only through a group effort was the product improved. As a member of the toy purchasing public, it's up to you to decide what this information means to you.