Blog: Internet Of Things

Jurassic Poke: Hacking a Dino toy

Jamie Riden 16 Mar 2017

The Cognitoys Dino is quite a cool IoT kids toy. It integrates with IBM Watson for interactive conversations with kids; it’s a shed load more secure than My Friend Cayla and CloudPets. Speaking for myself, I wouldn’t have an issue with my kids owning one.

However, that’s not to say that it is perfectly secure. It illustrates a common problem with IoT – that when first setting it up, the data exchange is hard to secure. It also has some fairly significant input validation issues in the web interface that we think shouldn’t be present

Getting started

First off, the iOS app looks OK in terms of communications – it seems to check that the SSL certificate is trusted, and uses an oauth2 login process and then Bearer token.

However the local web interface, that’s available over Wi-Fi on the toy, does have a few issues – CSRF and a persistent XSS amongst them. This is the result of entering as the SSID:

This the CSRF request I used to exploit the local web interface, which then makes use of the XSS.

We’ve showed elsewhere – for example at the end of this BT Wifi Extender article – how to do a spray around the local /24 using Google Chrome – so the fact that it’s on 192.168.15.146 doesn’t matter too much.

This shows spraying the CSRF to all the addresses on the local /24 – we can get the local IP address from Google Chrome. Firefox used to support this behavior but no longer does.

If you visit the web interface directly now you get:

The web server logs the following information:

And you can see the index file we’re serving here:

Of course, this could have been any code we like. So if we could convince the user to follow a link to the embedded web server on the toy, we can XSS them, persistently. I’m thinking a rogue support email and BeEF…

Fortunately, the users PSKs are not displayed in the web interface, so are not accessible to the JavaScript that we can run.

However, we could easily see the SSIDs that are set up, or set up a new one with high priority. We also get to see the external IP address of the affected device in our web server logs.

Plain text comms

You probably already spotted that the embedded web server is served over HTTP. The logical solution would be to implement SSL to prevent MITM, however this raises a challenge:

How do you implement SSL without a decent source of entropy on the IoT device?

The Cognitoy uses a TI MCU with very limited options for entropy: whilst it has a RNG, the TI NWP has exclusive access to it. A challenge that we hope will be revised in time. There are plenty of options for chipsets that can provide decent entropy, such as Freescale ARM, NXP Kinetis, Atmel SAM etc

Fixes needed are :

  • Properly HTML-encode the SSIDs (and all other data) before rendering it in the web interface
  • Do some CSRF checks, even if it’s just making sure the Referrer header is sensible.
  • Causing the user to set a password for the web interface on first use would be nice too.

Disclosure

Elemental Path were in fairness very quick to respond and we had a decent conversation with them. The bugs aren’t that serious given the context, but they are easy to fix and in our opinion should be.

We think they’re a cool vendor, but need to do a little work on the web UI for the Dino.

Timeline

2nd July 2016 – notified Elemental Path, did receive a response but it didn’t appear to address the issues.

16th October 2016 – contacted Elemental Path again, no response.