Connected camera cock up

I haven’t touched adult toy security for over a year now, mostly because we kept finding the same stuff over and over again. Besides, @internetofdongs has been doing some great work in this space, so it seemed pointless to duplicate his efforts.

However, this morning, @dcuthbert tweeted us this:

I wasn’t going to bother, as their mobile app was secure, or so it claimed:

But I just had to. Dan had thrown the gauntlet. What a story it turned in to!

I couldn’t resist…

Within 10 minutes I had found the following in the user manual. Unusually, the device uses Wi-Fi rather than Bluetooth, probably to support the bandwidth required for streaming.

Yes, that’s a static Wi-Fi pre-shared key. Subsequent findings indicated that it’s static and can’t be changed. Just like the Siime Eye.

The SSID is interesting too, easy to locate on https://wigle.net, not that I expect many to be found there.

Odd that the manual didn’t redact the other SSIDs in the example image.

So presumably one now has access to the device over Wi-Fi.

Next step is to enter a device UID and static password of ‘ok12345678’.

The UID is disclosed in the ‘LAN search’ function. Remember, the device is a wireless access point, not a client. The PSK is static, so anyone in range can join it.

Simply add the default password, and you’re joined to the video stream from the camera.

I’m sure every user will change that password on first use. Right?

As we don’t have one of these devices yet, we’ve gone pretty much as far as we can with the app.

Except that a quick look at the server which hosted the API endpoint was a default Django install that appears to support numerous different devices. This sounds systemic all over again!

Hardware

Now, the next step of any investigation in the absence of physical hardware is to look at the FCC filings. Photos of internals will reveal the chipsets and architecture in use, which can be useful in assessing whether a trusted execution environment (TXE) is present, among many security features. I searched the FCC database with no joy, so asked the question on Twitter:

It was an innocent question, but started in motion a series of events that didn’t end so well.

At this point, I had a call from a friendly chap from the vendor, asking for advice. This is unusual in IoT security disclosures, so I offered as much useful advice as I could in the situation. Starting with the original device manufacturer would be a good start, to see if they had pursed certification already.

Turns out that they had passed the product to @internetofdongs a while back who had provided some help too. That’s cool.

I also explained a bit about FCC and CE certification around RF for electronic products. I’m no expert on the detail, but passed on what I knew and shared relevant docs from the FCC web site.

Then this happened:

Which I was NOT expecting!

I can only surmise that conversations with the ODM in the Far East had revealed that FCC/CE certification had not been arranged in advance of the product launch. Oops.

Advice

The vendor here did a great job of responding fast to security researchers. Had they not made contact, I’m sure this could have spiralled out of control very quickly, like many IoT disclosures.

They sought independent advice early, though perhaps should have spent more time on the security of the set-up process.

Validation of its security would have been wise before going to market too.

Finally, certification is really important: it’s easy to miss critical requirements when taking product to market.

Next steps

As the product is no longer shipping we’re going to pause on this project, unless anyone we know has already bought one of these devices?

But, this has to be a record – 6 hours from investigations starting to a product being pulled from the market. Even Cloudpets didn’t manage that!