I've just read Troy Hunt's excellent summary of the CloudPets breach, and it got me thinking. I'm a big fan of those "movie snark" YouTube channels, something like CinemaSins where they take a film to pieces and list "Everything Wrong With" it. The same kind of idea struck me about this issue, it is the Suicide Squad of security practice; CloudPets didn't make one error, but made several errors which exacerbated the effects of the others.

Cinema Sins

Referencing CinemaSins mean you should be watching a video with high production values but instead you've just got a text only blog that really needs a livelier theme.... but putting that to one side, I think CloudPets committed twelve "security sins". Did I get them all? And bear in mind I've just read Troy's blog, I've carried out no extra investigation myself.

Firstly - what they did get right - the use of bcrypt. Bcrypt is recommended for password hashes as it includes a salt, and so greatly reduces the feasibility of being attacked using rainbow tables.

However, for what they did wrong, in no particular order:

CloudPets

  • Unnecessary Internet connectivity - I assume the MongoDB just needs to interface with the API, which is what interfaces with the phone apps, therefore the database doesn't need to be Internet facing at all.
  • No firewalling in place - just the fact that the MongoDB was exposed to the Internet, rather than any kind of any host or network based firewall being in place.
  • No database authentication - by default MongoDB does not used a password.
  • Using live data in development - as Troy explains, there's no apparent separation between live and development environments or data.
  • Not protecting your interfaces from known bad actors - while Shodan.io isn't necessarily a "bad actor", it does help your security if you block traffic from a service known to index vulnerable systems.
  • No security based email addresses in place - standard email addresses that should be run for each domain are specified in RFC 2142. While some of these are undoubtedly out of date ( usenet@ anyone? ), others, such as security@, should be implemented and monitored appropriately.
  • No network or security monitoring - the database was compromised multiple times and yet CloudPets obviously didn't spot this as they didn't react by securing their systems, or at least protecting the database server from the Internet.
  • Unencrypted data within the database - it strikes me that there could/should have been a clever way to encrypt the data in the database, maybe tied into a particular toy's hardware, or some key derived from the App associated with the toy. As the toy appears to talk using Bluetooth to an App within the same household, as that App acts as a gatekeeper for inbound and outbound messages; a key based on the toy might work. By cryptography standards it would be horrible, a shared key in multiple locations, and that would require little effort for the App to encrypt or decrypt voice data, but certainly better than nothing.
  • No authentication protecting online assets - the profile pictures, voice recordings, and so on are all accessible with knowledge of the complex URL they're hosted at. While not trivial to index this makes them vulnerable. The authentication credentials required are already available to the service, this is omitted simply because the service is so poorly secured.
  • No network separation - from Troy's article it looks like the webserver, the production database server, and the development database server, were either all sitting on the same IP address, the same physical or virtual system, or all were the same physical or virtual system. I assume it's difficult to elevate privileges from MongoDB access otherwise far more damage would have been caused by all the recent compromises, but this is a less than ideal configuration all the same.
  • No password policy in place - any password was permitted, including a single letter; as Troy points out the demo video uses "qwe", and judging by his article, the obvious choice of "cloudpets" was common.
  • No notification of compromise - as Troy illustrates through interrogating Shodan, CloudPets knew that there database had been compromised, but made no effort to contact their users. I can't comment on the legal situation here, but it's due to vendors like this that the inbound GDPR disclosure rules look so useful, or so concerning, depending on whether you're consuming or providing a service.

So that's the twelve. There was a couple more that sprang to mind around Threat Intelligence, and more fine grained database security, but they're too wobbly for this piece.

So what did I miss? Did I catch everything? Suggestions for what else they did wrong are welcome in the comments below.

And do sign up for Troy's haveIbeenpwned.com website too.