Not only was a huge amount of information exposed through a public, unauthenticated MongoDB instance, and not only did CloudPets ignore multiple security researchers' attempts to alert them to the problem, but the database was actually held for ransom multiple times without customers being alerted to the breach.
Seeing it light up and say "destroy all humans" was pretty funny, moreso because there is pretty much zero authentication on them so you could do it from anywhere from your mobile, and the mic can turn on and record without any authentication at all.
sigh internet of things
Publicity can work wonders. You end-up with sensitive data for kids in the wild, possibly in the hands of perverts, nothing could work better than that in raising awareness for the general public. It's harsh, but it fucking works. So we'll stick with it for now, unless someone comes with a better idea.
On the other hand, I don't know any better idea either.
Well I wouldn't say never, just needs some people determined to have it on the core of the team. Certs are free to low cost depending on the type you want. Compute needed for "Security" is minimal (Heck we can even do RootCA Validation on the the ESP8266 these days).
But this isn't directly connected to the internet and goes via Blue Tooth connection, issues like this are down to lax security practices.
> It's the opposite of profitable to care.
How much profit does it cut to not to put your mongoDB instance internet facing? Firewall off 27017 and Enable Auth shouldn't cut into their profits too much.
EDIT: Slapping a sig creation/check on the content urls shouldn't eat into profits either. This breach had nothing to do with the toy itself but was server side.
Wrong question. How much profit does it cut to hire an engineer who knows not to make your mongoDB instance Internet-facing and to empower that engineer enough that they can tell the CEO that the product is not ready to launch and they can't just open public access to the develop/test environment is the question. And it's not even a matter of profit. It's a matter of pride. Engineers are seen as typists and nerds, low level functionaries. They're the ones who don't understand the divine wisdom of "don't let the perfect be the enemy of the good enough."
You wonder why companies are so stupendously desperate for H1B visas and why so many job listings are looking for 2 years experience and no more? It's because they don't WANT knowledgeable staff. Those tend to be expensive, and problematic.
But the purpose of the device has nothing to do with the security of the device.
We're screwed coming and going, and the vast majority still look at you like a woodland hermit if you suggest that you shouldn't have anything listening to you in your home.
I realize that training data is important and I assume the recorded data gets used for that purpose but does Amazon need to keep it forever? How long do they need it? Can I own and posses the hardware and pass off the learning alone?
Is it feasible to install hardware with the capability of Alexa in the standard user's home?
I think the answer to that is probably "yes", more or less. Some things may be a bit harder to do but I don't see why I need a huge black box in the sky to parse my voice or do some geolocation.
But your lights, TV, etc. don't live in an Amazon datacenter.
In a world where it is just expected that you have a personal cloud server in your home Alexa becomes an "app" on that server and the Echo continues life as a very nice speaker/microphone device you can place in a visible area in order to interact with that server.
Edit: Demo of the CloudPets functionality using Web Bluetooth https://github.com/pdjstone/cloudpets-web-bluetooth/
I understand that this leak is related to mongodb... and that is terrible, but mostly referring to your bluetooth example.
I mean take bluetooth headphones they are notoriously insecure, but the range in which eavesdropping could take place is pretty small, and for most of us you would just be eavesdropping on our annoying music. Seems reasonable that they save bandwidth on secure transmission of data for higher audio quality. That said I could see an argument the other way, but I'm sure there are more examples where it doesn't seem like a big deal. It would be interesting to hear from someone who thinks I'm dead wrong.
Encrypting a compressed audio stream does not add to the bandwidth, aside from the initial key negotiation.
Furthermore, the bandwidth required for audio of a quality that's indiscernible from the original is negligible when compared to the bandwidth of Bluetooth radios. Ridiculously good audio is 320 kbps, and Bluetooth is easily good for 25 Mbps.
I suppose you could argue that the battery power used to perform this computation is the limiting factor, but a good embedded DSP used to perform the recording and transmission typically have tiny power requirements and hardware encryption routines that don't significantly change the power requirements of the device, as compared to keeping a blue LED blinking or powering an earbud speaker.
No, let's be honest here. The actual limiting factor is engineering time and money that goes into developing these devices as quick and cheaply as possible.
It's a bit paradoxical. There are way less things a kid can say that can get him in trouble than an adult. Even the most oppressive regime will not hold what a 4yo toddler says against him. The need for privacy should rather be less for a kid than for an adult.
What it means is that violations of privacy are creepy, period. We try to rationalise it by arguing that we get something out of it, but when dealing with our kids, we stop believing our own bullshit and it is just becomes purely creepy...
Also, It's not just recordings. Once an adversary has account access, they can talk to children. I can't imagine that being a good thing.
That's, unfortunately, the very reason why most of IoT stuff exists.
So I'm worried about my kid saying things that could get other people into trouble.
(No real source, but a random German article that quotes this anecdote: http://www.badische-zeitung.de/panorama/der-freundliche-herr...)
I remember when being a kid in school, the police were by for a visit to educate on alcohol responsibility, and touching on ethanol/methanol dangers since moonshine was a thing, they showed a distiller (which "if clearly meant for distilling spirits" is illegal to own), and some kid blurted out "my dad has one of those!" immediately when seeing it.
The teacher tried to claim "teacher-parent confidentiality" when asked to identify the kid/parents as if that's a thing, but I don't think they took it seriously enough to warrant further action.
Nevertheless; yeah, kids say everything.
>the average parent.. is technically literate enough to know the wifi password but not savvy enough to understand how the "magic" of daddy talking to the kids through the bear (and vice versa) actually works [or] that every one of those recordings... is stored as an audio file on the web.
If it is not considered amazingly stupid, or at least ignorant to not understand that the magic talking bear has a computer in it, and that if the computer wants the wifi password it probably uses the internet, and that if the entire purpose of the device is to make recordings available to you over the internet... then I despair. My sympathy for people who buy these sorts of products is wearing thin. But, in this particular instance...
>our tolerances are very different when kids are involved
Interesting. Why? The data is much less valuable:
>One little girl who sounded about the same age as my own 4-year old daughter left a message to her parents: "Hello mommy and daddy, I love you so much." Another one has her singing a short song, others have precisely the sorts of messages you'd expect a young child to share with her parents.
Hardly identity thief material.
I think you vastly overestimate the degree to which non-technical consumers understand computers, wifi, the internet, email, web sites, apps on their phone, and the differences and boundaries between any of those.
Because while we can make an informed decision about putting our own data into such a service, weighing up the risks and benefits, a four year old cannot - a parent is making that decision for them, and when you are making such a decision on behalf of someone else it behooves you to act more conservatively than when deciding on your own behalf.
It's the why-do-I-care-about-my-privacy argument - but it's even more personal now, because it's not just you, it's your kids.
There's always that extra creep factor when it comes to children.
True, but potentially very dangerous material in other ways. It's not hard to image kidnappers piecing together stolen audio clips to create fake messages as part of a ransom attempt. Or scammers creating audio clips to scare parents and extract money. A large bank of audio clips from a child could be used against that child's family in all sorts of ways, especially if the parents don't know the clips were stolen to begin with.
The real question is why you wouldn't already be terrified about having a microphone in your house that is open to the internet.
And even if this were a credible threat, logically we should be more concerned about direct financial theft since it has the same impact, but is far less elaborate (but still far less common than other types of cybercrime).
In Germany it works with grandparents. They get calls from someone impersonating their grand-child in trouble. This works because in many families grandparents live separately and sometimes don't have much contact to their grandchildren (apart knowing that they exist). This threat is so real that there are police posters about this in community centers.
So this works over text messages or phone calls without much sophisticated mimicing. I just imagine a whole new spin of this when AI/DL tech becomes a commodity.
So I quite disagree with the "movie plot" estimation of the threat.
Really though this is pretty cool, when not used for nefarious purposes.
Maybe just avoid anything with "cloud" in the name?
I do exactly that. I treat the word "cloud" in a product name (or feature list) as a huge negative indicator and steer clear.
Voice data was once safe in its obscurity... now I have a $2 app on my phone that can do decent voice transcription.
It's just one more thing to worry about.
Audio messages can be used to train a system which then will be able to mimic the voice of the child, almost indistinguishable from the original. AI of this kind will be commodity (i.e. easily accessible by criminals) pretty soon if not today.
I suspect some of it is so I've got the amazingly useful (nb: may not be useful at all) feature of being able to turn my lounge room lights on and off from my phone while not at home.
Cynical me suspects it's also probably a pretty good way to ensure forced just-put-of-warranty failures...
Pessimist-me assumes the Russians, the Chinese, Mossad, and some kid at the local hackerspace have all pwned the Chines cloud infrastructure and are using backdoor root shells on light globes subversive tshirt purchase history, and they're all cutting each other's throat price discounting as they sell it all as "business intelligence" to my car insurance company and the CBP...
And yes I also rant and rave about parents who post pictures of their children everywhere.
Someone steals the recording saying "Hello mommy and daddy, I love you so much."
They then manage to contact you, reporting that they have kidnapped your children. They play you the recording to prove they are in your custody and demand an immediate ransom payout.
Highly prone to error, not very likely to work, incredibly evil and likely to end up with the perpetrator in jail, but, unfortunately, the sort of thing that a desperate criminal might try, and even more unfortunately, it only needs to succeed once for someone to consider it a viable tactic.
I know this is stupidly unlikely occurrence, but extrapolate it with a bit more sophistication and you can start to see why this is actually quite nasty identity theft material.
Internet-of-Shit will remain exactly that until neglecting security is a substantial threat to the bottom line of a company.
They ignored multiple warnings? Got hacked multiple times? This is negligence, and this company should be fined out of business.
If you want one, they're now available for the low, low price of only $3. Including WiFi.
I wonder how children learning about these things from such a young age will play out once they're gron up.
'Internet of Things That Don't Work Anymore Because The Company That Made Them Has Gone Out Of Business, Oh, And Because Security'
I assumed that the security issues might be bad, but placing the voice on unsecured Mongo facing public Internet is beyond shit.
Thankfully, I have disabled the bear long time ago. But now I worry about my NetAtmo station, which contains an always listening microphone to "measure the noise pollution". Yeah, right.
Anything with a microphone might always be listening, and you probably can't (easily) verify whether it's on-demand or not ;-)
Put some CEOs in handcuffs, lock them in a cage like an animal, and see how quickly companies actually start doing crazy things like mentioning the word 'security' in job listings for software engineers or system administrators or even doing the unthinkable, hiring experienced expensive engineers.
How else would you do it?
Disable indexing on s3 and you need to know the direct link. Dump the table to get those links but then you still need to know the secret your app shares with s3 to create the sig needed to download from s3. I.E. They need to know Z and X and X only gets issued to people logged in and expires after a time. Knowing Z alone gets you nothing.
I do the same to protect the s3 bucket from direct access our cache pulls from (cache has a shared secret with s3 to pull from. Cache also has another signing process for the client to use to download from the cache). Client Signing for Z file is not valid for client+1. We just use a cache in-between client and s3 as we managed to get a deal thats cheaper for us then direct access to s3. But the same could be done for direct client to s3.
There is a German word for that. Datensparsamkeit.
Actually, and probably for the first time ever, I completely agree with Fowler:
"Datensparsamkeit isn't just about bad people stealing data, it's also about your relationship with the primary company themselves. The default attitude at the moment is that any data you generate is not just freely usable by the capturer but furthermore becomes their valuable commercial property. Privacy advocates, including me, think this assumption needs to be changed. Companies should only capture what they need and the burden of demonstrating need should fall on them. In addition, of course, they must be completely transparent about what they capture, what they store, and who they share their data with."
This, I believe, needs to be enforced by regulations, worldwide. Businesses won't do it themselves, because it's a clear case of conflicting social and monetary interests.
Upvoting you just for that. <3
Other than giving a false sense of security.
Even if the database is encrypted, something has to access the decrypted data and is vulnerable to attack.
Agreed though. Encryption is only a stopgap and the DB should never have been public in the first place.
And now audio of children has been hacked, exposing kids voices. The future is here, and it's weird.
Especially in this fashion?
Why can't we just have a BT connection between the device and the phone and IAPs in the phone if they must?
What is the significance of this being Mongo vs any other poorly/unsecured DB?
Other stores may let you get away with setting up "root/ root" or "admin/ password" but at least they have forced you to think about setting up some security. It's a trade-off, but it's a crappy one IMHO. There's no risk to Mongo, et al: they told you to set up security but didn't force you because they want you to pick their product.
Alas, that wont happen.
Remote access can be handled through a VPN, so there's no need for a remote server. I'm assuming that the device in question has computing hardware that's at least on par with a $9 CHIP.
What's really needed is for secure and easy to set up VPNs (to connect back to your home network) to become a thing, then the remote access problems are taken care of. After this, each IoT device's app just needs to look for the device and possibly give the user a gentle VPN reminder if it can't find it.
Of course, a VPN introduces a lot of extra work for the user. Even the steps to connect/disconnect from the VPN add enough friction that some people won't bother.
1. Consumer grade routers include a secure VPN endpoint. Whenever the router connects, it registers its internet-facing address with some vendor-specific DNS service under a name unique to that router but persistent at least until the router is factory-reset.
2. Devices on the local WiFi network can request a VPN access token. Optionally this requires a separate password set in the router, or pressing a physical button on the router a la WPS. As part of provisioning the token, the vendor-specific DNS name is also provided to the device. The provisioning process requires connecting back to a listening socket on the client device.
3. Devices (eg your mobile phone / tablet) provisioned with a VPN access token can then connect back in to your local network remotely. Each VPN access token is time-limited, configurable on the router but generally something in the range of 7 to 60 days. After the token expires you must connect back locally to the local network to renew it - renewal is blocked over the VPN connection itself.
4. The router interface can be used to list and manually revoke access tokens.
5. The client device can automatically connect to the VPN, eg when requested by an app for one of these IoT devices. On operating systems like Android and IOS, access to the VPN should be restricted to a specific granted permission.
I honestly think most of the pieces are there. My old router, an ASUS RT-AC56U, has an OpenVPN server built in. It also supports dynamic DNS through an Asus-provided service. iOS (and probably Android) supports VPN-on-demand.
This is basically all of the infrastructure needed to do what you suggest.
The only piece missing is the easy-to-use provisioning/management piece.
I think you could even have a BT pin, so it would require a little security (eg, neighbors don't have your pin). It should be relatively straightforward to have a BT profile for "token authority".
It certainly would be reasonably easy to use on most devices: just press button and connect to the token device.
Someone should really get to work on developing such a technology stack. /s
Sarcasm aside, I completely agree with you and as soon as someone offers iPhone/Siri level functionality in a simple package I think people will eat it up. I know the whole "personal cloud" thing is not new but as people realize the implications of putting all their data in the hands of complete strangers I think the market for such a device will take off.
Maybe the OpenVPN guys can do it? They've got clients for every platform and seem to be present in some consumer-grade routers. Infrastructure-wise, iOS has on-demand VPN capability and I'm sure Android does too.
All the pieces are there, the only thing it needs (as though it's a simple problem - it's not) is someone to wrap it up in a slick and easy-to-use interface.
I would love to see some of the features of iCloud moved into an Airport type device with expandable storage and modular hardware that I can simply swap out when it fails. I realize Siri level capabilities would take more hardware than the typical router contains but I feel like a Mac mini may even have the necessary horsepower to do the amount of cloud computing my iPhone requires in a day.
The hard parts are creating the map data to begin with and training the voice recognition but once those are complete why can't I just run them on local hardware?
For your examples:
- Backups - Agreed, these make sense and need the appropriate security guarantees.
- Siri - I can't think of anything it does that requires the voice recognition stuff to operate in the cloud. If this could all be done on-device, but with the ability to reach out to the cloud as required that would be cool.
- Maps - I'm torn. On one hand, it could be a local thing, but on the other hand there is a LOT of value added by it living in the cloud. Whenever my bus is moving slow, my first instinct is to pull up Google Maps and see where the accident is. It's shockingly accurate.
And some other stuff:
- File syncing/sharing (like Dropbox and friends) - Doesn't NEED to be a cloud service, this could be as simple as a USB hard drive attached to a router or as complex as a 12-bay NAS. What I'd love to see in this space is a universal API that app vendors can use - no more dealing with some apps that are Dropbox only when I want to use SugarSync or OneDrive etc. Then the storage provider would just provide an app that implements that API and everything that wants to store files in the cloud could use it.
- Email - I think what we have for email these days is really a great example of how things should work. Don't want to invest a lot of time and effort? Sign up for Gmail. You can use the web, or you can use a choice of native clients easily. Willing to put in the work? Buy a domain, get yourself a Digital Ocean droplet (or colocate a box - your choice!), and run your own.
I would rather none of my map usage or geolocation data ever went to the cloud. Yes, Google does aggregate a lot of valuable information but that could be consumed by personal devices directly instead of giving Google the ability to combine our travel habits with our eating habits and our browsing habits.
Bus arrival data isn't big or complex, Google just aggregates it which is why you go to maps but they don't actually put a GPS/Cellular device on every bus (excluding android phones >_>). They aggregate location data from the bus operator sources. I don't need to know where every bus in the United States is at every moment like Google does. I just need to know when my bus is reaching a stop near me. My home server could easily hit the same services Google does to get arrival data per stop or even just stay up to date on all the routes in my area or city.
Bus arrival data is public so there's no reason for me to store it locally but my usage of that data is personal and is something I want to own and control end to end.
A bear that records voices and gives remote access should not need to store data on a server. Store the data in the bear. That's the way these types of bears have always been. The only thing new here is remote access...
Storing my kid's private voice recordings on your server is just plain creepy even if you don't leave it wide open.
Based on how well the company is doing, it seems like this isn't really functionality that is deserved but it does sound like the justification for storing (some) messages is reasonable.
We have good security measures for connecting to servers (which is what IoT devices are) so why reinvent the wheel? Why not require devices to have normal TLS certificates and map the internal IP address to a subdomain of the manufacturer. That way browsers can access the device using CORS, and the normal XSS protections will apply. Authenticate and authorise using a well known standard like OpenID, OAuth or JWT.
Alas, that wont happen either
You really can't think of anything valuable about hooking up small devices/sensors to the internet? Do you really believe the potential for stronger security is so low that it's not worth investigating?
I work at an IoT company and we take security far more seriously than some would say is necessary or even reasonable. We're not the only ones out there, you just don't hear about us because our stuff works and therefore doesn't make the news. Just like you don't hear about all the miles an automated car drives safely.
Even if a self-driving car drives perfectly for 10,000,000 miles before swerving in to a crowd of people, no one is going to buy one.
Then you are a member of a miniscule minority.
The backing argument is a ballooning threat surface that can never reliably be patched
Some would convincingly describe Microsoft Windows the same way.
Also, I still don't know what problem is IoT supposed to solve.
Oil fields, someone drives out every day in a pickup, checks gauges.
Cool, let's just inundate the industry with pointless government "security" checklists that don't actually accomplish anything. That way, instead of a small fraction of all the cool, affordable products we now have access to occasionally getting hacked, we can just not have any cool, affordable products except those made by companies big enough to hire enough corporate lawyers to CYA their way to government approval.
How about, if you care so much about teddy bears getting owned, you just don't buy them? It's easier and more polite than taking them away from everyone else as well.
You can't legislate security into existence. That's not how it works. Security isn't a solved problem, so the government can't force people to do it correctly. The only think you can possibly accomplish is either making products more expensive (with no/negligible actual security benefit) or removing them from the market entirely.
Edit: I also wonder if stronger punishments for people involved in extreme cases like this would help. If you make a reasonable effort to secure your service and get hacked anyway that's one thing. But not even attempting to secure your service at all is something you shouldn't get away with. Of course the problem is how "reasonable effort" would be interpreted legally.
- use HTTPS
- no hardcoded security tokens in your requests
- any personal data stored is inaccessible to the outside world without AT LEAST a password
- minimum password length for users
just anything to slow the shitstorm combination of incompetent developers and corner cutting executives.
AND such regulations are reasonably easy to enforce, anyone can check network traffic to verify protocol and api tokens or setup a new account with a short password, port scanning would catch most public databases.
This sort of thing almost (but not quite) always results in things that are no more secure, just more bureaucratic. Large companies keep building the same insecure crap they always have but can afford to hire an army of lobbyists and paper pushers to get "approval". Small innovators who could actually fix the issue are kept out by the high cost of useless paperwork. The industry stagnates at a dismal low point.
In short, prematurely regulating an industry is usually a fantastic way to strand an industry at a local maximum far below its potential.
The regulators have so far been focused on the health aspects of the devices.
The point here was, there are always companies that are looking to make a quick buck and which will always refuse to "spend extra time and money securing it properly". Such companies have the market forces on their side - the less they give a shit, the faster and cheaper they can sell their products/services. Regulations in established industries ensure that the minimum level of giving a shit is still safe enough for people.