My Friend Cayla. Updated app; Updated security fails. How to make her swear (again!)

I’m sure you’ve read our post on making our internet-enabled interactive kids doll swear, and the creepy stalking consequences of the security bugs that led to it. We expressed significant concerns about the security of children using the doll; we don’t believe she has been secured appropriately, and said so publicly in the media.

The vendor responded some time ago, saying ‘We immediately developed a patch, and upgraded the software…’ yet as far as we can make out, the update has given virtually no benefit in terms of security.

Version 1.0.8 of the Android app appears to be current in the Play store, updated on 3rd June 2015. The only significant change related to security that we can see is that SQLCipher has been implemented. What does this mean? Simply that the local database has been encrypted. Worse, the encryption key is stored locally in the mobile app. It’s static.

FAIL

Here’s the offending code:

The last parameter of the call to super is the database encryption password. It’s a base64 string that we’ve obfuscated.

So if you wanted to make her swear, or say anything you like to the child, it’s still really easy:

As you can see, the ZBADWORD table contains 1357 entries. Use sqlite as above to edit the database as you see fit!

This is not acceptable! What should the developers have done to make her secure?

sqlcipher supports a facility known as rekeying which generates a unique key per device, re-encrypting the database. No more static key fails…

Then, store that key somewhere sensible, like the keystore, WHERE IT’S SUPPOSED TO BE STORED!

SSL is still missing from the app; communications between the app and the interwebs for the Android version, notably the Wikipedia API, are still over plaintext.

SSL and certificate pinning is a must, otherwise anyone within range can run a Wi-Fi man-in-the-middle attack against the kids interactions with the doll, having it say virtually anything the attacker wants.

Obfuscate the client side code heavily. Make it almost impossible to follow the code.

Finally, until a unique Bluetooth pairing PIN is implemented for the doll-to-mobile-device connection, it will always be open to an attacker using an older version of the app on a rogue phone.

We think the vendor has misunderstood the attack, as encrypting the database has done virtually nothing to secure the doll and app.